I have read the document (draft-ietf-opsec-bgp-security-01) and I’m in support of publication this document as a BCP. Some comments/suggestions below. I have not had chance to go through all the comments you have received so far on this list. Hence, sorry if some of mine seem like a repeat of comments from others.
At NIST, we had put together BGP security recommendations document several years ago. You may consider referencing it: R. Kuhn, K. Sriram, and D. Mongomery, “Border Gateway Protocol Security,” NIST Special Publication 800-54. http://csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf Some nits/comments follow: Consider defining inbound/outbound upfront. p.3, sec 1, para 1: ACL is access control list p.3, sec 1, para 1: this quoted phrase needs further clarity and can be rephrased / explained: “…. to avoid filtering transit traffic if not needed” section 5.1.1.1 title change: IPv4 special purpose prefixes section 5.1.1.2 title change: IPv6 special purpose prefixes section 5.1.2: replace “…described in this section if it is not capable of…” with “…described in this section if they are not capable of…” sec 5.1.2.1, para 1: replace “…keep checking prefixes in the IANA allocated address space …” with “…keep checking prefixes in the IANA allocated IPv4 address space …” sec 5.1.2.1, para 1: replace “…IPv4 prefixes they receive have been allocated…” with “…IPv4 prefixes they receive in BGP updates have been allocated……” sec 5.1.2.2, para 1: replace “…To overcome this risk…” with “…To partially mitigate this risk……” sec 5.1.2.3, para 3: replace “…a script can build for…” with “…a script can be built for……” sec 5.1.2.3, para 4: comment about “…only use information from sources representing the five current RIRs…” Question: Why not include the mirrored IRR data of major ISPs as well? I understand such data are readily available in the RADB. sec 5.1.2.3, para 5: replace “…may quickly vary over time…” with “…may frequently vary over time ……” sec 5.1.2.3, para 5: replace “…could even been considered…” with “…could even be considered ……” sec 5.1.2.4, last para: The validation procedure described is inaccurate and incomplete. So (per Randy’s suggestion as well) you may simply refer to RFC 6811 here. It may also be worth including RFC 6907 (the SIDR RPKI use cases document) as a reference here. Sec 5.1.4: It would be helpful if a definition of “local AS” is provided here. Sec 5.1.5.2: Acronyms pMTUd and uRPF should be spelt out. Sec 5.2.3.1, para 1: replace “is the same than the one for” with “is the same as the one for” Section 8, last bullet: Is there a practical example when an exception (accepting your own AS number in AS-path) is required? Thanks much. Sriram
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
