Re: [GROW] WGLC draft-ietf-grow-filtering-threats-03

[Pierre Francois <[e-mail]>]

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" <[e-mail]> 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 <[e-mail]>
> Date: Friday, November 21, 2014 at 12:43 PM
> To: "George, Wes" <[e-mail]>
> Cc: Peter Schoenmaker <[e-mail]>, "[e-mail]" <[e-mail]>
> 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.