Wes,
On Oct 10, 2014, at 7:43 PM, "George, Wes" <[email protected]> wrote:
> I've done another review pass.
Thanks a lot. Sorry it took us a little while to adapt to it.
Here come proposals to accommodate your review.
> Most of my previous comments have been addressed, and the document has
> improved a lot, but there are a couple of things still outstanding, as
> well as a few new comments. I think they need to be addressed before this
> proceeds to IESG, especially since the document won't even pass a NITS
> check right now (click NITS on the upper right of the HTML version of the
> document to see them).
>
> 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 ;)
>
> 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." ?
>
> 2.1 filtering can also be due to hardware limitations (the hardware is not
> capable of a full DFZ table). Basically "I don't care about other
> networks' TE deaggregation, I can't carry all of that fluff, so I'm going
> to filter deaggregates because other networks having to deal with some
> unwanted traffic shifts is better than my routers all falling over due to
> routing table bloat"
>
Indeed. We added (3) in the following.
Local filtering can be motivated by different reasons, such as: (1)
Traffic engineering, where an AS wants to control its local
outbound traffic distribution using only the policy applied to the
covering prefix. Such a practice was notably documented in [3] (2)
Enforcing contract compliance, where, for instance, an AS avoids a
settlement-free peer to attract traffic to one link by using
selective advertisement, when this is not allowed by their peering
agreement. (3) The need for Forwarding Information Base memory
preservation sometimes pushes ISP operators to filter overlapping
prefixes.
(to be adapted based on what we decide w.r.t. terminology)
> 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?
>
> 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."
>
> "In this case, not all traffic
> heading to the prefix 2001:DB8::/32 from AS64501 would no longer
> traverse AS64502. "
> I'm having trouble parsing the meaning of this sentence. What does "not
> all traffic" mean in this case? Some still does? Also may be cleaner to
> say "would traverse a different ASN" (instead of "would no longer
> traverse…")
It was an editorial mess-up (which may explain the previous point, sorry about
that)
text replaced by:
In this case, traffic heading to the prefix
2001:DB8::/32 from AS64501 would no longer traverse
AS64502. AS64502 should evaluate if solving the issues
originated by the unexpected traffic flows are worth the
loss of this traffic share.
>
> 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.
>
> references are still not standard to IETF format, and the distinction
> between URI and references with overlapping footnote numbers is
> potentially confusing. use another I-D as a guideline, or see p 14-15 of
> http://www.rfc-editor.org/rfc-style-guide/rfc-style
I acknowledge that editorial laziness should have not happened at this stage :-S
> Reference [3] no longer seems to be referenced in the text at all, and
I put it back.
> your references to [2] and [4] in the text would be more useful if they
> discussed the link between the proposed solution and the referenced paper
> in more detail. Right now the link between the two is not clear even after
> reviewing the reference.
[4] can be used for the purpose of detecting an unexpected traffic flow.
We have the sentence "Open source tools such as [4] can be used to this end"
there. Its documentation explicitly mentions how to do that.
[2] documents putting Internet in a VRF to provide different forwarding tables
to different peers on the same router.
(Emphasising on the challenges of doing so).
With such an architecture, it becomes possible to forward packets received from
a peer based and solely based on the paths you actually propagated to that
peer, and not
based on the global routing table of the router. As a result, if you did not
advertise a more specific path to a peer because only its covering one fits the
policy, you'll forward the packet
based on the covering one, and won't suffer from the policy violation because
the path you use fits your policy with that peer.
We modified the text to clarify this.
Different techniques could provide this functionality; however, their
technical implementation can be complex to design and operate. An
operator could, for instance, employ Virtual Routing Forwarding (VRF)
tables RFC4364 [8] to store the routes announced to a neighbor and
forward traffic exclusively based on those routes. [2] describes the
use of such an architecture for Internet routing, and provides a
description of its limitations.
In such an architecture, packets received from a peer would be
forwarded solely based on the paths that fit the path propagation
policy for that peer, and not based on the global routing table of the
router. As a result, a more specific path that would not be
propagated to a peer will not be used to forward a packet from that
peer, and the unexpected flow will not take place. Packets will be
forwarded based on the policy compliant covering prefix.
> 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.
> but either way, simply providing the reference with
> no additional discussion isn’t enough.
I hope it's clearer now.
>
> I see that the security considerations section has been added, but it's
> still pretty thin. It may be appropriate to reference the route leaks
> draft as a somewhat related type of routing security discussion,
I am struggling to incorporate that one. I end up saying "it's somewhat
related" :) .
> and at a
> minimum you need to be explicit in this section that there are really no
> existing or proposed tools to protect against that sort of behavior since
> filtering policy is mostly of local significance.
Well we documented some, but explain they are not practical, and all you can
practically do currently to protect yourself
is to monitor your network, detect unexpected flow (using [4] for example), and
manually react.
It is possible for an AS to use any of the methods described in this
document to deliberately reroute traffic flowing through another AS.
The objective of this document is to inform on this potential routing
security issue, and analyse ways for operators to defend against
them.
It must be noted that, at the time of this document, there are no
existing or proposed tools to automatically protect against such
behavior. Network monitoring allowing for the detection of
unexpected traffic flows exist, but automated configuration changes
to solve the problem do not.
>
>
> Nits:
> %s/economical/economic
> 4 - may want to use "proactive" instead of anticipant, since that's a more
> common antonym for reactive
Done.
Thanks a lot for your numerous contributions to this text.
Regards,
Pierre.
>
>
> Thanks,
>
> Wes
>
>
>
> From: Peter Schoenmaker <[email protected]>
> Date: Wednesday, October 1, 2014 at 8:57 AM
> To: "[email protected]" <[email protected]>
> Subject: [GROW] WGLC draft-ietf-grow-filtering-threats-03
>
>
> Hello group:
>
> I would like to initiate a working group last call on
> draft-ietf-grow-filtering-threats-03. Between the last last call and now
> we received feedback on the draft and the authors have updated the draft.
>
> Please review the draft and voice your opinion as to yea or nay on this
> draft. WGLC will end 17th October 2014.
>
> Abstract
>
> This document describes how unexpected traffic flows can emerge
> across an autonomous system, as the result of other autonomous
> systems filtering, or restricting the propagation of overlapping
> prefixes. We provide a review of the techniques to detect the
> occurrence of this issue and defend against it.
>
>
>
> Thanks
>
> Peter
>
>
>
>
> 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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
