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
