Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

[Robert Raszuk <[e-mail]>]

Wanghaibo,

Flow spec 5575 and 5575bis limits to what can be used as match criteria to
IPv4/IPv6 IP layer and transport layer headers:

*"The following sections define component types and parameter encodings for
the IPv4 IP layer and transport layer headers."*

Your proposal can not proceed under FlowSpec umbrella as packet's target
ASN is not carried in any of the packet headers so it can not be applied as
a packet ACL.

If you want to continue with this extension let's use a different SAFI and
preferable a different name.

Thx,
R.


On Mon, Nov 11, 2019 at 8:21 AM Wanghaibo (Rainsword) <
[e-mail]> wrote:

> Hi Jeffrey,
>
>         Thanks for your suggestion.
>
>         Flowspec is intended to match only the message fields.
>         Our solution here is an enhancement to Flowspec, which can
> effectively reduce the space of the flowspec.
>
>         The rules here are also used in conjunction with the existing
> Flowspec rules, so using the new SAFI to describe it is not appropriate.
>         We can increase OPEN capability negotiation to enable when this
> feature is supported.
>
>
> Regards,
> Haibo
>
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Saturday, November 9, 2019 1:11 AM
> To: Wanghaibo (Rainsword) <[e-mail]>; [e-mail]
> Cc: Robert Raszuk <[e-mail]>; [e-mail];
> Zhuangshunwan <[e-mail]>; idr@ietf. org <[e-mail]>
> Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow
> Specification
>
> Haibo,
>
> Thanks for the expected clarification.
>
> To the chairs, as noted below the feature violates some fundamentals of
> flowspec architecture.  I'd strongly object to the feature being adopted
> without a new SAFI to get it out of the existing flowspec use cases.
>
> -- Jeff
>
>
> > On Nov 7, 2019, at 8:48 PM, Wanghaibo (Rainsword) <
> [e-mail]> wrote:
> >
> > Hi Jeffrey,
> >
> >       Flowspec is designed for security protection, but current usage is
> not limited to security protection,
> >    but also to optimize traffic. Using Flowspec to optimize traffic is
> safer and more reliable than send routes to router.
> >
> >    Our scenario here is for optimize traffic. The actions here are all
> performed on the routers. You need to perform a FIB lookup to get dest-as.
> >
> >    This does violate some of the current rules and introduces a certain
> performance penalty,
> >    but it can reduce the demand for Flowspec entry space, so you can use
> this rule in the appropriate scenario.
> >
> > Regards,
> > Haibo
> >
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Friday, November 8, 2019 1:38 AM
> > To: Wanghaibo (Rainsword) <[e-mail]>
> > Cc: Robert Raszuk <[e-mail]>; [e-mail];
> > Zhuangshunwan <[e-mail]>; idr@ietf. org <[e-mail]>
> > Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow
> > Specification
> >
> > Haibo,
> >
> > On Tue, Nov 05, 2019 at 08:11:12AM +0000, Wanghaibo (Rainsword) wrote:
> >> PS: Netflow is already supporting statistical traffic based on
> Dest-IP-Origin-AS, it already download Dest-IP-Origin-AS to FIB entry, this
> prosess can be reused.
> >
> >> From a forwarding perspective, this is the detail that bothers me.
> >
> > Flowspec right now is currently independent of FIB state.  It functions
> on the firewall layer, which is typically implemented prior to FIB.
> >
> > What this feature implies is something roughly like:
> > Packet comes in, hits rule to check dst-as.
> > dst-as lookup needs to happen as one of:
> > - communicate to BGP routing process. (not likely to scale)
> > - trigger a FIB lookup, check returned dst-as.  Violates pipelining in
> > many  architectures.
> > - Have the entire FIB's dst-as-map pushed into memory for firewall,
> > implement as a longest-match lookup on that collection.
> >
> > -- Jeff
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>