I’ve reviewed previous versions of this draft, but made a new pass through it. I think it’s mostly ready to publish, though soliciting reviews from non-IETF operator lists might be a good thing to do before we go to IETF LC.
The abstract needs to remove the reference to MD5 since it is deprecated. Similarly, section 4.1 needs to explicitly note that MD5 has been deprecated by AO, not simply recommend that AO be used when available. I’ll concede that MD5 is better than nothing, but it’s not something we want to recommend in a new BCP without being clear why it shouldn’t be used anymore. There are places where words like “recommended" are used in ways that look to be 2119 usage, but are not capitalized. This needs to be consistent throughout the document, so that they are used whenever a recommendation is being made as something that you SHOULD/MUST do in order to be in compliance with this Best Common Practice. Section 3- may want to mention rate-limiting accepted traffic in addition to strict filtering of unacceptable traffic 4.1 – reference to BCP38 in the “block spoofed packets” section at the end? 5.1.2.3 – reference to IRRtoolset? 5.2.1 (or possibly section 8) - Filtering peer ASes inbound from customers? (in this case “peer” meaning a non-transit interconnect, not just someone you are connected to via BGP) I.e. If I know that I should only receive routes with 701 in the path from 701 because I do not use any other ASN as transit to reach 701, I should filter routes inbound from other sources to ensure that they don’t announce routes with that path. This is somewhere between the strict IRR based filters and the loose filters, and depends on the topology of the network and my business relationships, but I think it’s a useful point to make to add some additional safety filtering to prevent “my idiot customer is trying to re-announce the internet to me” along with max-prefix, which you already cover. Section 11’s future work either needs to be completed in this document or explicitly identified as work for a future document. The WG needs to discuss what is appropriate to add to this doc vs leave for future work before this proceeds. Section 12 needs explicit notes to the RFC editor to remove the section prior to publication. This may be something that the RFC editor will fix, but it would be preferable to use the actual draft name or RFC number as the reference tag instead of numeric tags, so that the reader knows what you are referencing without having to jump to footnotes each time. Thanks, Wes George From: "Gunter Van de Velde (gvandeve)" <[email protected]<mailto:[email protected]>> Date: Tuesday, April 8, 2014 at 5:18 AM To: opsec wg mailing list <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security Dear OpSec WG, This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security. Due to the time taken to integrate all comments from the first WGLC this 2nd WGLC is initiated. All three authors have replied, stating that they do not know of any IPR associated with this draft. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/> Please review this draft to see if you think it is ready for publication and comments to the list, clearly stating your view. This WGLC ends 22-April-2014. Thanks, G/ ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
