Camilo -
I'd like to echo a number of points that Wes made, specifically: Section 3.1 is confusing and seems to not provide useful information that is referenced later in the draft. A glossary of terms in the beginning to describe what you mean by the terms customer and peer and other terms used in this draft (or choose other terms) in terms of routes expected to be propogated and received may provide some clarity given in the modern peering climate customer does not always equate to full routes received and peer is a heavily overloaded term. The word "victim" in section 4 is fairly strong language for the resultant impact to networks of the discussed filtering techniques. A victim also implies a perpetrator, which may not be an accurate term for someone who may not have violated any agreement they have directly in place with their peers/providers. The last paragraph in section 4.2 seems a little odd to me. Presumably if an ISP offers community based filtering techniques for their customer use, and earlier in the same section you've said it's impractical for this draft to demand they stop offering such features, it is hard to imagine the scenario where the customer using provided communities is in violation of their term of use... although obviously any mumbo-jumbo could be written in a ToS/ToU, this seems unlikely as they could just not offer such communities for manipulation to customer if they didn't want them acted upon. I'd like to see these issues addressed before supporting this draft for WGLC. Thanks, Jon On 04/06/14 11:12 +0200, Juan Camilo Cardona wrote: > Wes, > > Thank you very much for this detailed review! We'll take a look at each point > in detail and try to improve the document as much as possible based on your > feedback. > > Camilo Cardona > > -----Original Message----- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of George, Wes > Sent: viernes, 30 de mayo de 2014 17:25 > To: Peter Schoenmaker; grow@ietf.org > Subject: Re: [GROW] WGLC draft-ietf-grow-filtering-threats-02 > > I think this draft has the potential to be useful, but it needs another > revision or two after getting some thorough reviews to get it there. I’ve > hopefully provided one substantive review below, but it needs others. > > NITS: > Some directional arrows to indicate the propagation of the routes (from which > ASN to which ASN) would help your diagrams immensely. > > Consistency: you use P and P’ to indicate the more/less specific routes in > the intro, but then use P/p in the examples. Capital/lowercase is much harder > to see if you’re reading quickly, especially in a diagram, and with a letter > like P, the difference between capital and lowercase is somewhat > font-dependent, and so I’d recommend sticking with P/P' > > > I echo Bruno’s comments about the nonstandard format for references, as well > as using RFC5737 documentation addresses instead of using 1918 addresses. > I do note that the examples use a /22 and /24s, while the 5737 prefixes are > all /24s, but the examples should work equally well using /24 and longer > prefixes. If not, it appears that the main goal is to demonstrate an > aggregate/deaggregate relationship, so the authors should also feel free to > use the IPv6 Documentation Prefix 2001:DB8::/32 and subnet it as necessary. > :-) Use of RFC5398 documentation ASNs in place of ASN1, 2, 3, 4, etc would > also be a good idea. > > ID nits also notes the fact that it’s missing an IANA considerations and > Security considerations section. > > Substantial comments: > Regarding the missing security considerations section: there’s a significant > discussion needed about the use of these methods to redirect traffic > maliciously. It’s somewhat related to the route leaks draft, and the general > idea of securing the routing infrastructure, but this is sort of the reverse > of a route leak, and to my knowledge, there are really no existing or > proposed tools to protect against that sort of behavior since filtering > policy is mostly of local significance. > > Structurally, I found this document pretty hard to follow. I think it would > be much easier to read if it discussed motivations first, either at the > beginning of section 2, or if the motivations are significantly different for > local vs remote filtering, at the beginning of section 2.1 and 2.2. This way > the draft would discuss why a given prefix might be locally or remotely > filtered, and THEN discuss the example of HOW. The introductory text seems to > imply that this is what the document will do, but the motivations are buried > at the end of the sections, and even then, you only obliquely and briefly > discuss them. I see that your current motivations reference traffic > management/engineering and policy enforcement (minimum prefix length), but I > didn’t see a reference to the other big one: Routing hardware scaling > limitations. > > It may also be useful to put the relevant parts of section 3 immediately > following each discussion of filtering, i.e. > Local filtering motivation/example > Unexpected traffic flows triggered by local filtering Remote filtering > motivation/example Unexpected traffic flows triggered by remote filtering > > I think you should remove most of section 3.1 and figure 4. It’s not a useful > precursor to the later examples and repeats a mistake made several places in > this draft (such as the beginning of section 4), which is that it starts with > a really generic and hand-wavey intro that almost reads like an abstract for > each section, telling the reader that the draft will be talking about > something in more detail in a subsequent section. Let’s compress things a > little and get right to the meat of the draft. This draft's individual > sections aren't long enough to need tl;dr summaries at the beginning of each > section, and IMO the examples in the other parts of section 3 stand on their > own without the one in 3.1. > > Section 4 has very little actual guidance on how to detect these incidents, > especially in 4.2, which mainly re-summarizes the points made elsewhere about > WHY an SP might do this. This section should be discussing the tools > available to see these things in addition to generally sketching what data to > look at. For example, *how* would an SP "monitor its traffic data and > validate if any flow > entering the ISP network through a non-customer link is forwarded to a > non-customer next-hop”? The second paragraph of section 4.1 is good, as it > discusses the BGP data analysis necessary, but would be better if it > identified one or more tools that allow for that sort of analysis, and > identified scenarios (if any) where these tools or the available data would > be inadequate. > I would also recommend different wording than “victim”, perhaps in terms of > originator vs propagator of the routes. It may not actually be useful to > differentiate between the different types (victim vs contributor) if the > methods to detect the occurrence of this sort of route filtering is the same > regardless of where you are in the path of the route’s propagation. > > 4.1 refers back to 3.1, but I’m not sure what it’s intending the reader to > recall from that section, since 3.1 did not really discuss what the > "different situations" were. > > In the end of 5.1 - how would an operator "account the amount of traffic that > has been subject to the unexpected flows”? > > > 5.2.1 - You’d be better off discussing this in terms of why it’s not a viable > solution instead of discussing it impassively. There are very few scenarios > outside of DoS attack traffic where blackholing traffic to solve a routing > problem is warranted, so the language needs to be a good bit stronger so that > it doesn’t read like a legitimate alternative. In IETF parlance, this is NOT > RECOMMENDED, or “considered harmful”. I also don’t understand what 5.2.2 is > trying to say that is distinct from 5.2.1. > There’s no discussion of the automatic part, and seems mainly to be a > continuation of that previous filtering discussion. > > 5.2.3 would be more useful if it discussed the proposed solution in more > detail, especially as regards the referenced paper. Right now the link > between the two is not clear even after reviewing the presentation. > Section 2.2 also references this solution, but is similarly unclear about how > it might help. It may be that there is another draft needed to discuss the > application of this solution to this problem rather than covering it here, > but either way, simply providing the reference with no additional discussion > isn’t enough. > > It would also be useful to explicitly state in section 5 that there are no > existing good systematic solutions to this problem, and that the draft is > discussing *potential* solutions > > > Thanks, > > Wes George > > > > On 5/21/14, 9:34 AM, "Peter Schoenmaker" <p...@lugs.com> wrote: > > >hello, > > > >I would like to call a second working group last call on > >draft-ietf-grow-filtering-threats-02. we issued a previous one in > >december but received no comments. The document is ready to publish, > >and now is your last time to support or comment. WGLC will end 6/6/2014. > > > >https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/ > > > >Abstract > > > > Network operators define their BGP policies based on the business > > relationships that they maintain with their peers. By limiting the > > propagation of BGP prefixes, an autonomous system avoids the > > existence of flows between BGP peers that do not provide any > > economical gain. This draft describes how unexpected traffic flows > > can emerge in autonomous systems due to the filtering of overlapping > > BGP prefixes by neighboring domains. > > > >Thanks > > > >peter > > > > > > > >_______________________________________________ > >GROW mailing list > >GROW@ietf.org > >https://www.ietf.org/mailman/listinfo/grow > > > 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 > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
