Last Call Review of draft-ietf-idr-bgp-flowspec-oid-13
review-ietf-idr-bgp-flowspec-oid-13-secdir-lc-nystrom-2021-05-08-00
Request | Review of | draft-ietf-idr-bgp-flowspec-oid |
---|---|---|
Requested revision | No specific revision (document currently at 15) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2021-05-05 | |
Requested | 2021-04-20 | |
Authors | Jim Uttaro , Juan Alcaide , Clarence Filsfils , David Smith , Prodosh Mohapatra | |
I-D last updated | 2021-05-08 | |
Completed reviews |
Rtgdir Early review of -11
by Geoff Huston
(diff)
Rtgdir Last Call review of -13 by Ron Bonica (diff) Secdir Last Call review of -13 by Magnus Nyström (diff) Secdir Telechat review of -14 by Magnus Nyström (diff) |
|
Assignment | Reviewer | Magnus Nyström |
State | Completed | |
Request | Last Call review on draft-ietf-idr-bgp-flowspec-oid by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/cXLfoahYLzvWRotWkFvIybgl_J0 | |
Reviewed revision | 13 (document currently at 15) | |
Result | Has issues | |
Completed | 2021-05-02 |
review-ietf-idr-bgp-flowspec-oid-13-secdir-lc-nystrom-2021-05-08-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes "a modification to the validation procedure defined for the dissemination of BGP Flow Specifications." More specifically. the memo describes a mechanism which relaxes the existing validation rule that requires Flow Specifications to be originating from the originator of the best-match unicast route, and now allows such specifications to be originated within the same AS as the validator. As a result. the Security Considerations section does call out: "The original AS_PATH validation rule ([RFC4271] section 6.3 <https://tools.ietf.org/html/rfc4271#section-6.3>) becomes hereby optional (section 4.2 <https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-13#section-4.2>). If that original rule is actually not enforced it may introduce some security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route...." and "If t[the originator of a rule] is known for a fact not to be a route server, that optional rule SHOULD be enforced for Flow Specification routes." It is not clear to me how a validator would now "for a fact" that a peer isn't a route server, and thus that it would have to enforce the now-optional path validation rule. It seems some clarity on this would be good such that implementations have less of a risk of accepting flow specifications from unauthorized parties, even if they are on the same AS. Editorial: - "Let's consider the particular case where the Flow Specification is originated in any location within the same autonomous system than the speaker performing the validation (for example by a centralized BGP route controller), and the best-match unicast route is originated in another autonomous system." - should the word "than" be replaced with "that" here? - In the security considerations section, "becomes hereby optional" could probably be simplified to "becomes optional" or similar, and "actually" could be removed. Thanks, -- Magnus