I've done another review pass.
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)
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.
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"
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.
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
"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...")
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.
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
Reference [3] no longer seems to be referenced in the text at all, and
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. 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, but either way, simply providing the reference with
no additional discussion isn’t enough.
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, 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.
Nits:
%s/economical/economic
4 - may want to use "proactive" instead of anticipant, since that's a more
common antonym for reactive
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
