Hi! > 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.
No problem! I haven't been able to answer to all the great coments we've received so far. Thanks for your support that's appreciated! > 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 I wasn't aware of it sorry. I believe this is highlighting that having an IETF BCP would be useful as no network operator can be aware of all the great material avalaible everywhere. > Some nits/comments follow: > > Consider defining inbound/outbound upfront. > > p.3, sec 1, para 1: ACL is access control list OK > 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” Clarified > section 5.1.1.1 title change: IPv4 special purpose prefixes OK > section 5.1.1.2 title change: IPv6 special purpose prefixes OK > 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…” OK > 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 …” OK > 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……” OK > sec 5.1.2.2, para 1: replace “…To overcome this risk…” with “…To partially > mitigate this risk……” OK > sec 5.1.2.3, para 3: replace “…a script can build for…” with “…a script can > be built for……” I don't think so. Full sentence is below so we are talking about the fact that the script builds something: "With these two mechanisms a script can build for a given peer the list of allowed prefixes and the AS number from which they should be originated" > 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. OK, changed to: One could check a popular IRR containing many sources (such as RADB, the Routing Assets Database) and only select as sources some desired RIRs and trusted major ISPs > sec 5.1.2.3, para 5: replace “…may quickly vary over time…” with “…may > frequently vary over time ……” OK > sec 5.1.2.3, para 5: replace “…could even been considered…” with “…could > even be considered ……” OK > 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. Yes we'll work further on the section globally. > Sec 5.1.4: It would be helpful if a definition of “local AS” is provided here. OK. Same here we should clarify few things here. > Sec 5.1.5.2: Acronyms pMTUd and uRPF should be spelt out. OK, will appear in accronym&definition section of -02 > Sec 5.2.3.1, para 1: replace “is the same than the one for” with “is the same > as the one for” OK > Section 8, last bullet: Is there a practical example when an exception > (accepting your own AS number in AS-path) is required? Well I've personnaly seen that when customers have a single AS for several sites and are interconnected through various ISPs. We are usually using other mecahnisms like as-override but I'd assume some would prefer to change default BGP bahaviour and agree on the risks. I am not sure we wanted to put an example in the document. Again, thanks a lot for your participation! Jerome _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
