Impact of BGP Filtering on Inter-Domain Routing Policies
RFC 7789

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

Alvaro Retana No Objection

Comment (2015-08-18 for -07)
No email
send info
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.

(Jari Arkko; former steering group member) Yes

Yes ( for -07)
No email
send info

(Joel Jaeggli; former steering group member) Yes

Yes ( for -06)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2015-08-19 for -07)
No email
send info
I think Robert Sparks followup Gen-ART review of version 07 deserves consideration:

https://mailarchive.ietf.org/arch/msg/ietf/rG31yTd2kDc8PaTCaoVyZ5ZJDbg

(Brian Haberman; former steering group member) No Objection

No Objection (2015-08-18 for -07)
No email
send info
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 steering group member) No Objection

No Objection ( for -07)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-08-20 for -07)
No email
send info
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 steering group member) No Objection

No Objection ( for -07)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-08-19 for -07)
No email
send info
- 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 steering group member) No Objection

No Objection ( for -07)
No email
send info