Skip to main content

Impact of BGP Filtering on Inter-Domain Routing Policies
draft-ietf-grow-filtering-threats-08

Yes

(Jari Arkko)
(Joel Jaeggli)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Jari Arkko Former IESG member
Yes
Yes (for -07) Unknown

                            
Joel Jaeggli Former IESG member
Yes
Yes (for -06) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2015-08-18 for -07) Unknown
I have a non-blocking comment related to the characterization of the unexpected traffic flows (and a nit).

Section 6. (Security Considerations)  Throughout the document the unexpected traffic flows were characterized as potential policy violations, not as routing security issues as is done here.  I know that the text has gone around the point of malicious intent (or not) before, but I think that if you’re going to mention that it could be a "potential routing security issue”, then you should say something more about it (even if it is the result of non-malicious intent) — or just leave it at policy violations.


Nit:

The example in Section 2.2.1. (Unexpected traffic flows caused by remotely triggered filtering of more specific prefixes) didn’t look good to me at first..then I re-read the text until I discovered that the other ASes (including 64505) are peering with both 64502 and 64503.  Because of how Figure 4 is drawn, it looks like 64505 is only connected to 64502.   Maybe centering that AS will avoid confusion.
Barry Leiba Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2015-08-19 for -07) Unknown
I think Robert Sparks followup Gen-ART review of version 07 deserves consideration:

https://mailarchive.ietf.org/arch/msg/ietf/rG31yTd2kDc8PaTCaoVyZ5ZJDbg
Brian Haberman Former IESG member
No Objection
No Objection (2015-08-18 for -07) Unknown
I have no issues with the publication of this document.  The following are simply voiced for your consideration...

1. I think the comment in 3.2 about how difficult it is to get routing policies from external entities is undersold.  Most organizations won't share that information since it might reveal business arrangements they consider proprietary.  I would suggest being explicit in the cause for the difficulty in obtaining such information.

2. Section 4.2.1 seems to be hinting at a UI deficiency in routing platforms in that a route filter installed in the control plane should automatically result in an ACL installed in the forwarding plane.  That sounds like an intriguing capability.

3. All of the approaches described in section 4 seem littered with caveats on their effectiveness. Is there any definitive data on the effectiveness of these techniques?
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-08-20 for -07) Unknown
Please add in the proposed text from the SecDir review to address his questions:
https://www.ietf.org/mail-archive/web/secdir/current/msg05855.html

Additionally, I'd like to see the Security Considerations mention a point brought up earlier in the draft, namely that the filtering could cause traffic to be routed back through a path that doesn't have information for that more specific AS.  As such, this essentially could cause a DoS on that traffic until the BGP route allows for the new path for the more specific AS.  The importance of mentioning this int he security considerations section is to more explicitly call this out as a potential DoS attack method.  The time for BGP to repropagate might be short(ish), but that could be a critical amount of time during an event and maybe the more specific AS is a web server farm or some other critical resource.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-08-19 for -07) Unknown
- intro 1st sentence confuses me at least. The 2nd paragraph
does explain it nicely though when I get to page 3. Maybe try
re-word that opener? Or just delete para 1?

- Figure 4 is mentioned in 2.2.1, and includes AS65404, but
that ASN is not mentioned in the text in that section which is
confusing, or is there a typo? I also didn't quite follow the
description in 2.2.1 either which may be related or
independent;-)

- I'm guessing, but didn't check in detail that -07 includes
changes from the secdir review [1] (which raised some nits).
If so, thanks!

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05853.html
Terry Manderson Former IESG member
No Objection
No Objection (for -07) Unknown