First, I will state for the record that I do _not_ think the SIDR working group should take this as a "baseline" draft for BGP AS Path validation without serious rework. Specific points:
== 3.3 As cryptographic payloads and loading on routers are likely to seriously increase, a BGPsec design may require use of new hardware. It must be possible to build routers that do BGPsec with within acceptable (to operators) bounds of cost and performance. This should be left out of any requirements document, and various proposed system compared based on their costs and deployment difficulty. == 3.7 If message signing increases message size, the 4096 byte limit on BGP PDU size MAY be removed. Has anyone done any analysis of the impact of increasing the MTU size on all BGP speakers on the Internet at large? Before making such a blanket statement, I would like to hear from vendors and operators about the impact of such a change. == 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple NLRIs in a single UPDATE, given the impossibility of splitting a signed message while preserving the signature. I'm not certain why this would be in a requirements document. Can anyone explain how this directly relates to the security of BGP? IE, what is the direct relationship between stating that packing is no longer needed in BGP, and improving the security of BGP itself? This should be completely removed from the requirements list, and left open as one point of consideration between competing proposed systems. == 3.14 A BGPsec design MUST NOT require operators to reveal proprietary data. This includes peering, customer, and provider relationships, an ISP's internal infrastructure, etc. Though it is understood that some data are revealed to the savvy seeker by BGP, traceroute, etc. today. What sense does it make to say the only system which may be deployed is one that protects information already publicly available? This is a non-requirement, and must not be included in the requirements list. == 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the UPDATE has traversed the AS path indicated in the UPADTE. Note that this is more stringent than showing that the path is merely not impossible. I've always thought requirements documents proposed a set of requirements, rather than a set of end goals. This entire "bullet" needs to be replaced with a realistic set of requirements concerning what can, and cannot, be proven about an AS Path in BGP, and then what we can actually require. What does "proving the AS Path the update has traversed," prove, precisely? Does receiving an update through a specific path prove traffic sent to that destination will traverse the path listed? Does receiving an update prove that all destinations listed are reachable along the path listed? Does receiving an update prove that every AS along that path has agreed to forward traffic transmitted to the destination indicated? It proves none of the above. The document needs justification, not assertions. == 4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design MUST provide a mechanism to control the window of exposure to replay attacks. Again, this is an assumption which I completely and totally disagree with. What is the window size allowed in terms of time? Is it minutes, hours, days, weeks, months, or years? == In short, this document does NOT accurately reflect the needs or requirements of BGP security, and should NOT be adopted as a WG document. Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
