Wes, Thank you again for all your detailed comments and recommendations. Please give us a few days to take a careful look at them and come back with an answer.
Regards, Camilo Cardona On 10 Oct 2014, at 19:43, George, Wes <[email protected]> wrote: > I've done another review pass. > Most of my previous comments have been addressed, and the document has > improved a lot, but there are a couple of things still outstanding, as > well as a few new comments. I think they need to be addressed before this > proceeds to IESG, especially since the document won't even pass a NITS > check right now (click NITS on the upper right of the HTML version of the > document to see them). > > May want to consider the terminology with relation to SIDR's definitions > of covered prefixes. Right now it conflicts and can be potentially > confusing, so you might want to use a different term. (see RFC 6907) > > I don't understand why this is titled "making BGP filtering a habit" as it > is really discussing problems with BGP filtering, rather than advocating > doing it. > > 2.1 filtering can also be due to hardware limitations (the hardware is not > capable of a full DFZ table). Basically "I don't care about other > networks' TE deaggregation, I can't carry all of that fluff, so I'm going > to filter deaggregates because other networks having to deal with some > unwanted traffic shifts is better than my routers all falling over due to > routing table bloat" > > 3.1 - may want to specifically mention BGP anomaly detection tools, i.e. > tools that monitor the BGP table via one or more looking glasses, and > alert when a significant change is detected. While these won't detect > constant/consistent prefix filtering, they should detect new instances > since they'll look different from previous snapshots. > > 4.1 "stop announcing covering prefix" - add text to warn of the need to > make sure that there are other subnet prefixes that cover the rest of the > covering prefix. your examples use /32 and /34. If you remove the /32, you > need to add additional announcements to make sure that there is still > reachability to the rest of the /32 (the other 3 /34s) that is not > included in the more specific /34. Have to consider whether this is > already permitted through the upstream BGP filters or may cause the > opposite effect of providing a more specific route for those other > prefixes now instead > > "In this case, not all traffic > heading to the prefix 2001:DB8::/32 from AS64501 would no longer > traverse AS64502. " > I'm having trouble parsing the meaning of this sentence. What does "not > all traffic" mean in this case? Some still does? Also may be cleaner to > say "would traverse a different ASN" (instead of "would no longer > traverse...") > > 4.2.1 "configure its routers to install dynamically an access-list..." -- > how? Feature name? Is this commonly supported, or specific to a set of > vendors? > Dynamically implies that this is done automatically via some sort of > background process in the router, rather than based on a manual, but > changing configuration, so it may just be that you need to clarify that > this is done manually but may change frequently. > > references are still not standard to IETF format, and the distinction > between URI and references with overlapping footnote numbers is > potentially confusing. use another I-D as a guideline, or see p 14-15 of > http://www.rfc-editor.org/rfc-style-guide/rfc-style > Reference [3] no longer seems to be referenced in the text at all, and > your references to [2] and [4] in the text would be more useful if they > discussed the link between the proposed solution and the referenced paper > in more detail. Right now the link between the two is not clear even after > reviewing the reference. It may be that there is another draft needed to > discuss the application of the referenced solution to this problem rather > than covering it here, but either way, simply providing the reference with > no additional discussion isn’t enough. > > I see that the security considerations section has been added, but it's > still pretty thin. It may be appropriate to reference the route leaks > draft as a somewhat related type of routing security discussion, and at a > minimum you need to be explicit in this section that there are really no > existing or proposed tools to protect against that sort of behavior since > filtering policy is mostly of local significance. > > > Nits: > %s/economical/economic > 4 - may want to use "proactive" instead of anticipant, since that's a more > common antonym for reactive > > > Thanks, > > Wes > > > > From: Peter Schoenmaker <[email protected]> > Date: Wednesday, October 1, 2014 at 8:57 AM > To: "[email protected]" <[email protected]> > Subject: [GROW] WGLC draft-ietf-grow-filtering-threats-03 > > > Hello group: > > I would like to initiate a working group last call on > draft-ietf-grow-filtering-threats-03. Between the last last call and now > we received feedback on the draft and the authors have updated the draft. > > Please review the draft and voice your opinion as to yea or nay on this > draft. WGLC will end 17th October 2014. > > Abstract > > This document describes how unexpected traffic flows can emerge > across an autonomous system, as the result of other autonomous > systems filtering, or restricting the propagation of overlapping > prefixes. We provide a review of the techniques to detect the > occurrence of this issue and defend against it. > > > > Thanks > > Peter > > > > > 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. > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
