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

["George, Wes" <[e-mail]>]

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