Re: [Idr] John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)

["Juan Alcaide (jalcaide)" <[e-mail]>]

Hi,

We talked internally and we don't think it's worth pursuing. It would enhance security as defined in [RFC8955] (what is not the purpose of this draft), and upset all
existing implementations. There is nothing forbidding any implementation to enhanced security in this way via a knob if they think it's suitable.

But we need to modify the explanation because it didn't fit the new rule. We also introduce the concept of instead of suggesting to enforce neighbor-AS match of FS, suggesting to just to enforce it on the unicast route.

Please take a look to make sure it's accurate and clear.


# Revision of AS_PATH Validation -> Explanation

Comparing only the left-most AS in the AS-PATH for eBGP learned
      Flow Specification NLRIs is roughly equivalent to checking the
      neighboring AS.  If the peer is a route server, security is
      necessarily weakened for the Flow Specification NLRI, as it is for
      any unicast route advertised from a route server.  An example is
      discussed in the Security Considerations section.

      Redefinition of this AS_PATH validation rule for a Flow
      Specification does not mean that the original rule in [RFC8955]
      cannot be enforced as well.  Its enforcement remains optional per
      [RFC4271] section 6.3.  That is, a BGP speaker can enforce the
      first AS in the AS_PATH to be the same as the neighbor AS for any
      address-family route (including a Flow Specification address-
      family route).  If the BGP speaker peer is not a route server,
      when enforcing this optional rule, the security characteristics
      are exactly equivalent to those specified in [RFC8955].

      Alternatively, enforcing this optional rule for unicast routes
      (even if not enforced on Flow Specification NLRIs) achieves
      exactly the same security characteristics.  The reason is that,
      after all validations, the neighboring AS will be the same as the
      left-most AS in the AS-PATH for the unicast route, and the left-
      most AS in the AS_PATH for the unicast route will be the same as
      the left-most AS in the AS_PATH for the Flow Specification NLRI.
      Therefore, the neighboring AS will be the same as the left-most AS
      in the AS_PATH for the Flow Specification NLRI (as the original
      AS_PATH validation rule in [RFC8955] states).


# Security Considerations

If configuration (or other means beyond
   the scope of this document) indicates that the peer is not a route
   server, that optional rule SHOULD be enforced, for unicast and/or for
   Flow Specification routes (as discussed in the AS_PATH Validation
   section, just enforcing it in one address-family is enough).


-J



> Do we really want to match only the last-AS, or as many ASes as we 
> want?  The paragraph above in the explanation would seem to favor as many AS_PATHS as we can. Transit ASes could still originate FS rules.
> 
> Ex:
> 
> Validate         Unicast: 100 101 102 103, FS: 100 101
> Do not validate  Unicast: 100 101 102 103, FS: 100 102

That's a fair point. If you want to update the doc accordingly though, it would be a significant enough technical change that I think you would need to go back to the WG for discussion of it. Your call (and Alvaro and the IDR chairs’).