Subject: [GROW] WGLC draft-ietf-grow-filtering-threats-02

From: Peter Schoenmaker <[email-masked]>
Date: Wed, 21 May 2014 13:34:14 +0000

hello,

I would like to call a second working group last call on draft-ietf-grow-filtering-threats-02.  we issued a previous one in december but received no comments.  The document is ready to publish, and now is your last time to support or comment.  WGLC will end 6/6/2014.

https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/

Abstract

   Network operators define their BGP policies based on the business
   relationships that they maintain with their peers.  By limiting the
   propagation of BGP prefixes, an autonomous system avoids the
   existence of flows between BGP peers that do not provide any
   economical gain.  This draft describes how unexpected traffic flows
   can emerge in autonomous systems due to the filtering of overlapping
   BGP prefixes by neighboring domains.

Thanks

peter

---

From: <[email-masked]>
Date: Wed, 21 May 2014 13:55:31 +0000

Hello,

Support.
draft-ietf-grow-filtering-threats documents operational issues/surprises that may happen with route filtering. This is useful to document and be able to reference.

Nits: 
- the document uses, as example, the prefix "10.0.0.0/24" (from rfc 1918) while IMO it should use a block from rfc 5737 http://tools.ietf.org/html/rfc5737
- in section 7 "References",
	-  the doc should make a distinction between normative and informative references
	- there is a 7.2 but no 7.1
	- I'm not sure what is meant with "URIs" versus regular references. I would rather put these drafts as reference with their full name and authors.

Thanks,
Bruno

> -----Original Message-----
> From: GROW [mailto:[email-masked]] On Behalf Of Peter
> Schoenmaker
> Sent: Wednesday, May 21, 2014 3:34 PM
> To: [email-masked]
> Subject: [GROW] WGLC draft-ietf-grow-filtering-threats-02
> 
> hello,
> 
> I would like to call a second working group last call on draft-ietf-grow-
> filtering-threats-02.  we issued a previous one in december but received no
> comments.  The document is ready to publish, and now is your last time to
> support or comment.  WGLC will end 6/6/2014.
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 28 May 2014 17:57:00 +0100

On 21/05/2014 14:34, Peter Schoenmaker wrote:
> I would like to call a second working group last call on
> draft-ietf-grow-filtering-threats-02.  we issued a previous one in
> december but received no comments.  The document is ready to publish,
> and now is your last time to support or comment.

looks good to me.  support.

Nick

---

From: "George, Wes" <[email-masked]>
Date: Fri, 30 May 2014 11:24:37 -0400

I think this draft has the potential to be useful, but it needs another
revision or two after getting some thorough reviews to get it there. I’ve
hopefully provided one substantive review below, but it needs others.

NITS:
Some directional arrows to indicate the propagation of the routes (from
which ASN to which ASN) would help your diagrams immensely.

Consistency: you use P and P’ to indicate the more/less specific routes in
the intro, but then use P/p in the examples. Capital/lowercase is much
harder to see if you’re reading quickly, especially in a diagram, and with
a letter like P, the difference between capital and lowercase is somewhat
font-dependent, and so I’d recommend sticking with P/P'

I echo Bruno’s comments about the nonstandard format for references, as
well as using RFC5737 documentation addresses instead of using 1918
addresses.
I do note that the examples use a /22 and /24s, while the 5737 prefixes
are all /24s, but the examples should work equally well using /24 and
longer prefixes. If not, it appears that the main goal is to demonstrate
an aggregate/deaggregate relationship, so the authors should also feel
free to use the IPv6 Documentation Prefix 2001:DB8::/32 and subnet it as
necessary. :-)
Use of RFC5398 documentation ASNs in place of ASN1, 2, 3, 4, etc would
also be a good idea.

ID nits also notes the fact that it’s missing an IANA considerations and
Security considerations section.

Substantial comments:
Regarding the missing security considerations section: there’s a
significant discussion needed about the use of these methods to redirect
traffic maliciously. It’s somewhat related to the route leaks draft, and
the general idea of securing the routing infrastructure, but this is sort
of the reverse of a route leak, and to my knowledge, there are really no
existing or proposed tools to protect against that sort of behavior since
filtering policy is mostly of local significance.

Structurally, I found this document pretty hard to follow. I think it
would be much easier to read if it discussed motivations first, either at
the beginning of section 2, or if the motivations are significantly
different for local vs remote filtering, at the beginning of section 2.1
and 2.2. This way the draft would discuss why a given prefix might be
locally or remotely filtered, and THEN discuss the example of HOW. The
introductory text seems to imply that this is what the document will do,
but the motivations are buried at the end of the sections, and even then,
you only obliquely and briefly discuss them. I see that your current
motivations reference traffic management/engineering and policy
enforcement (minimum prefix length), but I didn’t see a reference to the
other big one: Routing hardware scaling limitations.

It may also be useful to put the relevant parts of section 3 immediately
following each discussion of filtering, i.e.
Local filtering motivation/example
Unexpected traffic flows triggered by local filtering
Remote filtering motivation/example
Unexpected traffic flows triggered by remote filtering

I think you should remove most of section 3.1 and figure 4. It’s not a
useful precursor to the later examples and repeats a mistake made several
places in this draft (such as the beginning of section 4), which is that
it starts with a really generic and hand-wavey intro that almost reads
like an abstract for each section, telling the reader that the draft will
be talking about something in more detail in a subsequent section. Let’s
compress things a little and get right to the meat of the draft. This
draft's individual sections aren't long enough to need tl;dr summaries at
the beginning of each section, and IMO the examples in the other parts of
section 3 stand on their own without the one in 3.1.

Section 4 has very little actual guidance on how to detect these
incidents, especially in 4.2, which mainly re-summarizes the points made
elsewhere about WHY an SP might do this. This section should be discussing
the tools available to see these things in addition to generally sketching
what data to look at. For example, *how* would an SP "monitor its traffic
data and validate if any flow
   entering the ISP network through a non-customer link is forwarded to a
non-customer next-hop”? The second paragraph of section 4.1 is good, as it
discusses the BGP data analysis necessary, but would be better if it
identified one or more tools that allow for that sort of analysis, and
identified scenarios (if any) where these tools or the available data
would be inadequate.
I would also recommend different wording than “victim”, perhaps in terms
of originator vs propagator of the routes. It may not actually be useful
to differentiate between the different types (victim vs contributor) if
the methods to detect the occurrence of this sort of route filtering is
the same regardless of where you are in the path of the route’s
propagation.

4.1 refers back to 3.1, but I’m not sure what it’s intending the reader to
recall from that section, since 3.1 did not really discuss what the
"different situations" were.

In the end of 5.1 - how would an operator "account the amount of traffic
that has been subject to the unexpected flows”?

5.2.1 - You’d be better off discussing this in terms of why it’s not a
viable solution instead of discussing it impassively. There are very few
scenarios outside of DoS attack traffic where blackholing traffic to solve
a routing problem is warranted, so the language needs to be a good bit
stronger so that it doesn’t read like a legitimate alternative. In IETF
parlance, this is NOT RECOMMENDED, or “considered harmful”. I also don’t
understand what 5.2.2 is trying to say that is distinct from 5.2.1.
There’s no discussion of the automatic part, and seems mainly to be a
continuation of that previous filtering discussion.

5.2.3 would be more useful if it discussed the proposed solution in more
detail, especially as regards the referenced paper. Right now the link
between the two is not clear even after reviewing the presentation.
Section 2.2 also references this solution, but is similarly unclear about
how it might help. It may be that there is another draft needed to discuss
the application of this solution to this problem rather than covering it
here, but either way, simply providing the reference with no additional
discussion isn’t enough.

It would also be useful to explicitly state in section 5 that there are no
existing good systematic solutions to this problem, and that the draft is
discussing *potential* solutions

Thanks,

Wes George

On 5/21/14, 9:34 AM, "Peter Schoenmaker" <[email-masked]> wrote:

>december but received no comments.  The document is ready to publish, and
>now is your last time to support or comment.  WGLC will end 6/6/2014.
>

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.