Hi George, > I’ve reviewed previous versions of this draft, but made a new pass through it.
First thanks a lot for your help on this doc! > 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. Doc has already been presented RIPE and NANOG meeting as you know. Should we simply send an email recalling this is last call? > 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. I'll remove MD5 from the abstract. For section 4.1 I propose the following text for 2nd paragraph you're referring to: TCP sessions used by BGP can be secured with a variety of mechanisms. MD5 protection of TCP session header [14] was the first existing mechanism. It is now deprececated by TCP Authentication Option (TCP-AO, [10]) which offers stronger protection. IPsec can also be used for this purpose. While MD5 is still the most used mechanism due to its availability in vendor's equipment, TCP-AO and MD5 SHOULD be preferred when implemented. Feel free to change the text. > 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. OK. > Section 3- may want to mention rate-limiting accepted traffic in addition to > strict filtering of unacceptable traffic Maybe a note on that. We probably don't want to start discussing the right thresholds here. > 4.1 – reference to BCP38 in the “block spoofed packets” section at the end? Good point. I remember there was BCP38 at some stage but we removed it and forgot to add it again when we added this small paragraph in 4.1 > 5.1.2.3 – reference to IRRtoolset? OK for a reference. > 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. I think that first bullet of section 8 is saying this. We are saying we need to make sure we receive only identified ASes from customer, we probably don't need to add we have to filter the ones we don't want. Tell me if I didn't understand your point. Feel free to propose some modified text. > 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. Indeed. Idea is indeed to remove this section: I forgot it was here. Comments were integrated except the one about IRRTOOLSET. Adding a reference is enough I think, probably don't need to give examples in appendix. > Section 12 needs explicit notes to the RFC editor to remove the section prior > to publication. Sure, I think I'll even remove this section in next version. > 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. If RFC editor can fix it I buy the idea. Otherwise you need to explain to me how to do it easily :) Thanks again for your comments. They will be integrated really soon. Please let me know about the text I proposed in 4.1. Jerome > > > Thanks, > > Wes George > > > From: "Gunter Van de Velde (gvandeve)" <[email protected]> > Date: Tuesday, April 8, 2014 at 5:18 AM > To: opsec wg mailing list <[email protected]> > Cc: "[email protected]" > <[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/ > > 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 -- Jerome Durand Consulting Systems Engineer - Routing & Switching [email protected] - +33 6 35 11 60 50 blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr twitter: @JeromeDurand linkedin: http://fr.linkedin.com/in/jeromedurand CISCO France 11, rue Camille Desmoulins 92782 Issy les Moulineaux CEDEX 9 FRANCE _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
