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

Matthieu Texier <matthieu@texier.tv> Thu, 24 August 2017 14:00 UTC

Return-Path: <matthieu@texier.tv>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6904F1326F4 for <idr@ietfa.amsl.com>; Thu, 24 Aug 2017 07:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js3yGvF12ITn for <idr@ietfa.amsl.com>; Thu, 24 Aug 2017 07:00:32 -0700 (PDT)
Received: from 3.mo2.mail-out.ovh.net (3.mo2.mail-out.ovh.net [46.105.58.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B52B132518 for <idr@ietf.org>; Thu, 24 Aug 2017 07:00:31 -0700 (PDT)
Received: from player770.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo2.mail-out.ovh.net (Postfix) with ESMTP id 044D7A9643 for <idr@ietf.org>; Thu, 24 Aug 2017 16:00:29 +0200 (CEST)
Received: from matthieu-laptop-2.home (LFbn-1-12338-186.w90-91.abo.wanadoo.fr [90.91.142.186]) (Authenticated sender: matthieu@texier.tv) by player770.ha.ovh.net (Postfix) with ESMTPSA id 6FBCC3C007E; Thu, 24 Aug 2017 16:00:27 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Matthieu Texier <matthieu@texier.tv>
In-Reply-To: <36E285C0-C716-437A-806D-A453273146DD@juniper.net>
Date: Thu, 24 Aug 2017 16:00:27 +0200
Cc: idr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CD58B23-6137-4604-968C-83A2F218FF79@texier.tv>
References: <36E285C0-C716-437A-806D-A453273146DD@juniper.net>
To: "John G. Scudder" <jgs@juniper.net>
X-Mailer: Apple Mail (2.3273)
X-Ovh-Tracer-Id: 15851826266559826646
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrtdeggdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2vUQ2nu3id6da8A720BKkV4ZD_Q>
Subject: Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules"
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Aug 2017 14:00:35 -0000

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 <jgs@juniper.net> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr