BGP Experiment

Owen DeLong owen at delong.com
Wed Jan 9 19:33:36 UTC 2019



> On Jan 9, 2019, at 10:37 , Töma Gavrichenkov <ximaera at gmail.com> wrote:
> 
> On Wed, Jan 9, 2019 at 9:31 PM Owen DeLong <owen at delong.com> wrote:
>> So if I understand you correctly, your statement is that everyone
>> should be (potentially) rebooting every core, backbone, edge,
>> and other router at least once or twice a week…
> 
> Nope, this is a misunderstanding. One has to *check* for advisories at
> least once or twice a week and only update (and reboot is necessary)
> if there *is* a vulnerability.
> 
> Checking is quite different from, actually, updating. What you may
> want to encourage your competition to do is to deploy a piece of
> software which actually *gets* a severe CVE twice in a week; that will
> certainly bring you a bunch of new customers.

Fair enough, but the frequency of vulnerability announcements even in some of the best implementations is still more often than I think my customers will tolerated reboots.

At the end of the day, this is really about risk analysis and it helps to put things into 1 of 4 risk quadrants based on two axes… Axis 1 is the likelihood of the vulnerability being exploited, while axis 2 is the severity of the cost/consequences of exploitation.

Obviously something that scores high on both axes will have me rolling out the upgrades as rapidly as possible, likely within 24 hours to at least the majority of the network.

Something that scores low on both axes, conversely, is likely not worth the customer disruption and support call volume (not to mention SLA credits, etc.) that come from doing that level of maintenance on short notice (or without notice).

The other two quadrants are a grey area that becomes more of a judgment call where other factors specific to each operator and their customer profile will come into play.

Some operators may have a high tolerance for high-probability low-cost problem, while others may find this very urgent, for example.

Owen




More information about the NANOG mailing list