RE: [RPSEC] Re: draft-convery-bgpattack-00

["Joel M. Halpern" <[e-mail]>]

What I see in S-BGP and this discussion is:

1) An approach that attempts to comprehensively provide security for BGP
2) An approach that for deployment probably requires significant 
enhancements in the actual routing hardware (storage, increased memory, 
crypto hardware).

It seems this overlooks several things:
A) The indications are that operators are not interested in (or possibly 
even capable of) deploying solutions with this complexity
B) We could probably get a lot of coverage (but not as complete) with a 
much simpler solution or set of solutions.
C) Securing BGP this carefully when the rest of the infrastructure is 
completely insecure seems almost counter-productive.

Note that currently many operators do not deploy source address filtering, 
or even martian address filtering with their customers.  And that is only 
the tip of the iceberg of simple things that need to be done.  It would 
seem that whatever energy it would take to even begin serious development 
and deployment of S-BGP could be much better spent getting some of the 
simple steps that are necessary deployed.  Then we could examine again to 
determine what makes sense to do next based on that experience.

Yours,
Joel M. Halpern

At 05:07 PM 11/7/2002 -0500, Stephen Kent wrote:
>Iljitsch,
>
>>On Wed, 6 Nov 2002 [e-mail] wrote:
>>
>>>  >IMHO - "Security requirements" that force Internet capital spending and
>>>  >network wide maintenance windows to deploy are not going to be adopted by
>>>  >the operations community.
>>
>>>  Not a surprising development and reminiscent of the auto manufacturers'
>>>  stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
>>>  focus is the bottom line always want to be shown a financial incentive.
>>>  "How about 'survival'?" seems to be unpersuasive.
>>
>>Routers are a lot like regular computers in many ways, but you can only
>>expect to sell a very small number compared to computers. I'm not a
>>router builder but I think that's the reason why router CPUs are so slow
>>compared to those of regular computers: the design costs to keep up with
>>the latest CPU technology would be too high.
>
>The performance of the CPU used for BGP varies from model to model and 
>from vendor to vendor.
>
>>As far as I can tell, verifying a signature takes in the order of a
>>millisecond on a decent CPU. So with 115,000 routes in the global
>>routing table, that's 2 minutes to initialize BGP, assuming one
>>signature must be checked per route. I don't think this is acceptable,
>>especially not considering router CPUs may be slower, there is other
>>processing to do as well and the expected growth of the global routing
>>table. This means routers must be equipped with crypto modules.
>
>We realized long ago that startup transients could be a serious timing 
>concern, and so we have suggested that routers destined to support S-BGP 
>would ideally have non-volatile storage sufficient to hold a recent copy 
>of the RAs, as well as the AAs and PKI data. Few (if any) routers deployed 
>today have this cap[ability, but it would be cheap to provide in the 
>future, e.g., flash memory prices are fairly low even today.
>
>>Then there is memory. There are still many routers in production that
>>are already in trouble memory-wise as their design allows only 32, 64 or
>>128 MB and a Cisco needs 256 MB to comfortably run BGP. I've tried to
>>add up all the extra fields but I couldn't be sure how much of what goes
>>where, but it looks like S-BGP will take at least twice the memory of
>>regular BGP.
>
>Again, no argument that currently deployed routers would not generally 
>have sufficient memory to hold all the RAs if everyone ran S-BGP, but then 
>these routers would probably no longer be in use by the time everybody 
>would be ready to run S-BGP. The factors (to first order) that determine 
>the extra memory requirements under S-BGP are the number of ADJ-RIBs the 
>router holds, the number of routes in the RIBs, and the average path 
>length for the routes. The total memory requirement is a function of these 
>factors, plus the extent to which S-BGP is deployed, i.e., the fraction of 
>routes that are S-BGP protected. In any case, we're not talking about more 
>memory than my laptop and desktop have, and the costs are not great, but 
>you are right that most routers in use today simply do not have the 
>ability to support enough memory, although some do. But, as noted above, 
>the initial stages of incremental deployment would not need as much extra 
>memory as full deployment.
>
>>This means some routers must be replaced completely and all others need
>>hardware upgrades. So expect resistance from the people who have to pay
>>the bill. Especially if there is so much of a byte wasted in your packet
>>formats, or there is a place where crypto is used when the same result
>>could be obtained without it.
>
>Yes, routers would need to be replaced over time, but routers are replaced 
>over time anyway, so the question is in part one of timing, and 
>incremental deployment is, by definition, staged over time. Also, it would 
>be possible to use ancillary devices with multi-hop BGP to avoid a "fork 
>lift upgrade" for some routers, if one can tolerate managing the extra boxes.
>
>Steve
>_______________________________________________
>RPSEC mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/rpsec


_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec