Wes, Thank you for your answers. Well, I agree with everything you said.
Thanks again, Pierre. On Jan 26, 2015, at 6:53 PM, "George, Wes" <[email protected]> wrote: > Sorry for the delay in responding. This sort of fell through the cracks in my > email. Responding only to open questions, snipping out anything that has been > updated to address my concerns or otherwise doesn't need a response. > > Thanks, > > Wes > > > From: Pierre Francois <[email protected]> > Date: Friday, November 21, 2014 at 12:43 PM > To: "George, Wes" <[email protected]> > Cc: Peter Schoenmaker <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: [GROW] WGLC draft-ietf-grow-filtering-threats-03 > > >> >> 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) > > > Indeed. For the sake of clarity of the discussion, the conflict you mention > is that a covering (ROA) prefix in rfc6907 is an exact match or a less > specific of another one, while > for us it's strictly a less specific. > > Hum, in the past I was using "less specific prefix" and "more specific > prefix". Shall I revert to this terminology? > > We thought about using the same as draft-white-grow-overlapping-routes-03 , > which I think we should do anyway as we are talking about > the same thing, but they use… "covering route", so I guess you are going to > give them the same comment ;) > > WG] well, I hadn't reviewed that draft to the level that I have yours, but > yes the same concern applies. :-) > I think more/less specific is fine, but if you want an alternative way to > represent the fact that the more specific is a subset of the less specific, > you could maybe use sub-prefix, or parent/child prefix, or maybe > supernet/subnet. > >> >> 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. > > You are right. > What about: "Impact of BGP filtering on Inter-Domain routing policies." ? > > WG] yes that's much more accurate. > >> 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. > > We know of research papers by one of our colleagues doing this actually > (checking consistency of more specific advertisement from different > monitoring boxes), and have heard gossip about some commercial tools, but I > have > no reference to the description of publicly available tools, or publicly > available product documentation. > > If I don't have such a reference, I'll end up saying "one can check for > policy violations every time its network management tool says that IDR state > has changed". > That's a bit weak, no? > > Any suggestions? > > WG] So generally we try to avoid recommending a specific tool, so my comments > were more suggesting that you roughly sketch what an anomaly detection tool > would do and how it could be helpful. The only publicly-available one that > I'm aware of is BGPMon, but the presence of multiple other research-level > tools is encouraging, as there should be other options available in this > space. The key point here is really to establish a baseline for the network > and its routes, and analyze what data is available to determine when detected > changes are normal "background radiation" vs something that goes against > policy or expected behavior (though expected behavior flirts with that loaded > term "intent", which is hard to define when talking about global routing). > > >> >> 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 > > Mmmm actually what we were saying is that the operator (64502 in the example) > can actually stop servicing the /32 (of his customer) at that peer, as a > whole. > > What you are saying is that this is quite aggressive, and you are trying to > be gentle and keep on servicing other overlapping more specifics (that > may indeed be routed without going against the policy of the AS). > > However, if the provider originates these /34 to do what you want, he's > forging a path to prefix belonging to its customer. I am feeling > uncomfortable writing text reading like a recommendation to do that. > > That's why we had written "AS64502 should evaluate if solving the issues > originated by the unexpected traffic flows are worth the > loss of this traffic share." > WG] I agree that originating the prefixes goes a bit far. I was more thinking > in terms of looking to see whether there was existing prefixes to match those > other /34s before determining that this was the right course of action. It's > a more specific example of what you're saying, so I think we're in agreement. >> >> 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. > > The envisioned feature name was "Wes", indeed :-D > > Note that I end up explaining why I am recommending to not do that in the > next paragraph. > So clearly I am not trying to have a vendor provide an automation of such a > feature. > > It is something we've heard in the past as being "THE solution to the > problem", and I wanted to document why we think it is not the case, in order > to not be asked to promote > it (as a router feature, or as a recommended operational procedure). > > It would also be a nightmare for an operator to maintain that on his own, as > you explained. I added on that, thanks. > > Suggested replacement for this subsection: > > An operator could install access-lists to prevent unexpected traffic > flows from happening in the first place. In the example of Figure 5, > AS64502 would install an access-list denying packets matching 2001: > DB8::/34 associated with the interface connecting to AS64504. As a > result, traffic destined to that prefix would be dropped, despite the > existence of a valid route towards 2001:DB8::/32. > > The operational overhead of such a solution is considered high as the > operator would have to constantly adapt these access-lists to > accommodate inter-domain routing changes. Moreover, this technique > lets packets destined to a valid prefix be dropped while they are > sent from a neighboring AS that may not know about the policy > conflict, and hence had no means to avoid the creation of unexpected > traffic flows. For this reason, this technique can be considered > harmful and is thus not recommended for implementation. > WG] yes, this is much clearer > > >> 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, > > Mmmm I'd like to not do too much paperware on this. It will make this wg work > a lot for not a lot of gain, IMO. > > I see the interest of documenting on "Putting the Internet in a VRF", but it > should provide more general considerations than what is needed for this > draft. > > WG] yeah, not suggesting that you need to write another draft here, just that > if you wanted to go into greater detail, there's probably another draft to be > had. Though in addition to what you've added, it probably would be worth > noting something about the fact that putting the internet "in a VRF" is > somewhat counter to the idea of doing this type of filtering because you have > hardware limitations, unless you are doing it on big, burly hardware at the > edges to protect much less capable hardware elsewhere in the network that is > not carrying all of these VRFs. > > > 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
