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

 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