Skip to main content

Last Call Review of draft-ietf-idr-bgp-flowspec-oid-13

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
Reviewed revision 13 (document currently at 15)
Result Has issues
Completed 2021-05-02
 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 <>) becomes
hereby optional (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.


   - "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.

-- Magnus