[Idr] Re: Flowspec redirect-ip update

[Nat Kao <[e-mail]>]

Hi, Jeff.

After reading -03 of this draft, I have an open question regarding
redirecting traffic into Next-Hops with tunnels from a user's point of view.
Assume:
    - A redirect-to-IPv4 EC with target address T is attached to an FS
route F
    - The best route towards T is R

For per-destination steering into an SR-Policy, we have two choices to put
a Color-EC:
    - If we put the Color-EC on F, it's the case described by
draft-ietf-idr-ts-flowspec-srv6-policy.
      In this case, we treat F more like a service route.
    - If we put the Color-EC on R, T will be the Next-Hop with a tunnel.
      In this case, we treat R more like a service route.
I think either case would work if we don't put the Color-EC on both F & R.
Do we have suggestions for this?

Thanks!

Regards,
Nat

On Sun, Sep 8, 2024 at 6:18 PM Jeffrey Haas <[e-mail]> wrote:

> In support of closing out lingering work, plus addressing a dependent
> document MISSREF, here's an update to the flowspec redirect-to-ip work.
>
> Known lingering issues are covered in my github where this work was
> originally being tracked:
>
> https://github.com/jhaas-pfrc/draft-ietf-idr-flowspec-redirect-ip/issues
>
> Redirect-to-ip for flowspec is supported in various forms across multiple
> vendors at this point.  The remaining work is addressing what the current
> inconsistencies and lingering operational security considerations will mean
> for the final form of this document.
>
> Summary of known issues:
> - The "C" bit for copy behavior is not believed to be implemented by anyone
>   at this time.  However, since most of the supporting implementations are
>   with vendors that do support some form of traffic cloning, we perhaps
> have a
>   desire to leave this bit defined in order to future-proof the protocol
>   extension.
> - Since this feature has dire consequences for traffic interception if the
>   redirection address is not strongly controlled, there is new text
>   addressing validating the redirection address vs. the destination
> address in
>   a fashion similar to existing inter-AS/eBGP flowspec.  And very similar
> to
>   that mechanism in the flowspec RFCs, it may be disabled by configuratino.
> - Compound actions in flowspec are known to be challenging, and already a
>   discussion point for enhancement in flowspec v2.  In this draft, the
>   compound action of redirect-to-vrf present in the base flowspec RFCs may
> be
>   augmented with a redirect-to-ip.  At this time, this compound behavior is
>   not believed to be implemented.  However, the authors had been contacted
>   about preserving this encoding to support future use cases.
> - ECMP traffic distribution is inconsistently implemented.  It's not
>   believed that this is a problem but is worth flagging to the working
>   group.
>
> Please review the update to the draft and provide feedback, especially if
> you have an implementation of this feature.
>
> -- Jeff (for the authors)
>
> ----- Forwarded message from [e-mail] -----
>
> Date: Sun, 08 Sep 2024 02:58:28 -0700
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-ip-03.txt
>
> Internet-Draft draft-ietf-idr-flowspec-redirect-ip-03.txt is now
> available. It
> is a work item of the Inter-Domain Routing (IDR) WG of the IETF.
>
>    Title:   BGP Flow-Spec Redirect-to-IP Action
>    Authors: James Uttaro
>             Jeffrey Haas
>             Andy Karch
>             Saikat Ray
>             Pradosh Mohapatra
>             Wim Henderickx
>             Adam Simpson
>             Matthieu Texier
>    Name:    draft-ietf-idr-flowspec-redirect-ip-03.txt
>    Pages:   9
>    Dates:   2024-09-08
>
> Abstract:
>
>    Flow-spec is an extension to BGP that allows for the dissemination of
>    traffic flow specification rules.  This has many possible
>    applications, but the primary one for many network operators is the
>    distribution of traffic filtering actions for distributed denial of
>    service (DDoS) mitigation.  The flow-spec standard [RFC5575] defines
>    a redirect-to-VRF action for policy-based forwarding.  This mechanism
>    can be difficult to use, particularly in networks without L3 VPN
>    infrastructure.
>
>    This draft defines a new redirect-to-IP flow-spec action that
>    provides a simpler method of policy-based forwarding.  The details of
>    the action, including the IPv4 or IPv6 target address, are encoded in
>    newly defined BGP extended communities.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-ip/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-idr-flowspec-redirect-ip-03.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-flowspec-redirect-ip-03
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> ----- End forwarded message -----
>
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>