Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules"

[Robert Raszuk <[e-mail]>]

Hi Matthieu,

IMO the RFC is quite clear that "A specific packet is considered to match
the flow specification when it matches the intersection (AND) of all the
components present in the specification."

That effectively means to me that to match packets which will be last
fragment or first fragment one would need to inject two separate NLRIs. At
this is guarantee to work.

Making assumption that implementation does OR among type 12 bitmask values
would actually remove ability to match on broken packets on the wire which
may actually have messed up IP headers and both bits set in the respect of
fragmentation - don't you think ?

Kind regards,
R.


On Thu, Aug 24, 2017 at 4:00 PM, Matthieu Texier <[e-mail]> wrote:

> Hi John and All,
>
> I would like to apologise re-opening this quite old mail thread but as I
> am working on a development, I am questioning myself on a very specific
> aspect of flowspec filtering.
>
> I would like to discuss nlri filtering type 12 - Fragment. This discussion
> is valid for both the existing RFC and this proposed draft.
>
> In all filtering nlri that requires bitmask (tcp flags, DSCP), the RFC
> 5575 is defining the encoding of the nlri value as the exact same way as it
> is encoded in the IP header itself.
>
> For the bitmask type 12, the RFC rather propose to use “pre-defined”
> values like IsF, FF, DF, LF.
>
> There are two observations I would like to highlight:
>
> 1) This approach creates a sort of inconsistency between filters: I tend
> to believe that the approach of Flowspec filters was to filter according to
> a header pattern (just like with DSCP and TCP flags flowspec nlri). If we
> follow the same approach for fragments, we should normally propose a nlri
> value made of the fragment flags (3 bits) and eventually 1 bit to specify
> if fragment offset have to null or not.
>
> 2) The bitmask of nlri type 12 as define could create odd router behavior
> or misalignment between implementations:
>
> Assuming that routers identifies the first fragment by checking that MF
> bit is set to 1 and that the offset set to 0. How a router could consider a
> nlri with a bitmask having Isf and FF set to one ? Does it have to do an
> implicit OR between the Isf and FF ?
>
> Considering my first observation and following the same logic as with DSCP
> and TCP flags, if I want to filter packets that are fragments or first
> fragments, I should normally send two values with an explicit OR operator
> between the two.
>
> It might be implemented that way in certain OS but I am afraid that RFC is
> not perfectly clear on this particular situation.
>
> Does it make sense to other people of the group or it is only me torturing
> myself ?
>
> Thanks,
> Matthieu.
>
>
>
>
> > On 21 Jan 2017, at 16:03, John G. Scudder <[e-mail]> wrote:
> >
> > Hi All,
> >
> > The authors have requested IDR working group adoption of
> draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules".
> Please send your comments to the list.
> >
> > This adoption call will conclude on Monday, February 6.
> >
> > Thanks,
> >
> > —John
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>