Subject: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 23:35:05 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-flow-spec-v6-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. It is indeed due time to filter
also those IPv6 packets ;-)

Please find below one blocking DISCUSS point, some non-blocking COMMENT points,
and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

I am puzzled by the absence of a flow spec for the first Next-Header being a
specific value and by the absence of a flowspec for the occurence of any
extension header in the extension header chain. Extension headers are an
important difference compared to IPv4 and could be 'nasty' as well (e.g.,
hop-by-hop header). Why was this not considered by the authors ? Or is there
another document in the WG to address this issue ?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

-- Section 3.1 --
Smart idea to have an offset but I wonder whether "Offset < Length < 129" is
true... Esp. with some IPv6 addresses with an embedded IPv4 address (32 bit) at
offset 96. Isn't "Offset + Length <= 128" better ?

-- Section 3.3 --
How is the upper-layer defined here? Basically, how a node can determine
whether it is an extension header or an upper-layer header? While I agree that
there are not too many new upper-layer protocols being specified, I would
prefer to have a definition of "upper-layer" here either by listing (or
referring to a IANA registry) all existing extension headers (then all 'next
header' not being 'extension header' are by default 'upper layer') or
vice-versa.

-- Section 3.6 --
Just curious ;-) Why is bit 7 not used in this encoding ?

-- Section 3.7 --
I share Ben Kaduk's concern about the encoding of the flow label in less than
20 bits.

== NITS ==

-- Section 3.1 (and possibly others) --
Sometimes the field 'length' is all lower case and sometimes it is capitalized.

-- Section 3.8.2 (and possibly others) --
Please use RFC 5952 to write IPv6 addresses.

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 4 Nov 2020 15:10:31 +0100

Hi Éric,

Thanks for your review of the document. Please see my comments inline, I think this should clear your DISCUSS. I also attached a updated document that contains changes resulting from your comments.

Since the draft submission is closed now I will ask Alvaro to publish the changed document today.

Cheers Christoph

> ## DISCUSS:

We discussed matching on extension headers in general. But this is a little bit of a moving target. It also seemed to have very limited advantage to match on the next-header-id values only (except for the upper-layer protocol). The flexibility to also match on the "content"/"encoding" of extension headers is not the scope of this document. Flowspec in general in its current specification (as extension of rfc5575bis) is not very extensible. The match for every new extension-header and its properties would most probably introduce a new FS component (something that is not easily possible). To overcome such limitations, there are discussions in IDR with the working title "FS 2.0" that should overcome the extensibility problem.

> ## COMMENT:

No, the Length is not the number of bits to match. The number of bits to match is Length - Offset. Length is the bitnumber in the address where matching ends.

> header' not being 'extension header' are by default 'upper layer') or

This is the term used in RFC8200 for the "last" next-header. It also explains how to detect the upper-layer protocol.

> Just curious ;-) Why is bit 7 not used in this encoding ?

The reason for this is to keep the flags aligned with the Fragementation-Flags in rfc5575bis (IPv4). rfc5575bis has matching on DF bit there.

> I share Ben Kaduk's concern about the encoding of the flow label in less than

I answerd this question in response on Benjamins DISCUSS. 

> Sometimes the field 'length' is all lower case and sometimes it is capitalized.

I updated the document accordingly

> Please use RFC 5952 to write IPv6 addresses.

As of Benjamin's comments I also added a paragraph to explain the notation, which is needed to repress the range for the pattermatching.

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 4 Nov 2020 11:22:46 -0500

Eric:

Hi!

To avoid possible extra work/churn, I’ll wait for you to confirm that the
changes address your concerns — or until we work through them — before
asking the Secretariat to post an update.

Thanks!

Alvaro.

On November 4, 2020 at 9:10:51 AM, Christoph Loibl ([email-masked]) wrote:

Thanks for your review of the document. Please see my comments inline, I
think this should clear your DISCUSS. I also attached a updated document
that contains changes resulting from your comments. Since the draft
submission is closed now I will ask Alvaro to publish the changed document
today.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 4 Nov 2020 17:53:23 +0000

Hello Alvaro,

Expect my reply either my European evening or my European Thursday morning as I had no time yet to check the reply

-éric

From: Alvaro Retana <[email-masked]>
Date: Wednesday, 4 November 2020 at 17:22
To: Eric Vyncke <[email-masked]>, Christoph Loibl <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Jie Dong <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Eric:

Hi!

To avoid possible extra work/churn, I’ll wait for you to confirm that the changes address your concerns — or until we work through them — before asking the Secretariat to post an update.

Thanks!

Alvaro.

On November 4, 2020 at 9:10:51 AM, Christoph Loibl ([email-masked]<mailto:[email-masked]>) wrote:
Thanks for your review of the document. Please see my comments inline, I think this should clear your DISCUSS. I also attached a updated document that contains changes resulting from your comments. Since the draft submission is closed now I will ask Alvaro to publish the changed document today.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 4 Nov 2020 21:21:58 +0100

Hi Eric,

> Why was this not considered by the authors ? Or is there another document
in the WG to address this issue ?

Actually it was considered :) I wrote the first version of this draft and
after discussion with co-authors and industry peers we decided to make any
extension header extensions for flow-spec to be out of scope of the base
document.

The main reason was (and I believe still is) fact that extensions headers
are work in progress and the number of extension headers are being defined.

So while it is clearly valid to have this Next Header check we were for now
trying to focus on base IPv6 header to provide analogy to IPv4 header
functionality.

If you think this is a show stopper I guess we would need to go back to the
drawing board and halt all progress made with this document that far.

Many thx,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Nov 2020 20:02:54 -0500

Eric:

I want to underscore one point Christoph made for your review in the morning. 

The WG purpose for this version of flowspec (RFC5575-bis) was to fix existing issues (bugs, v6, within AS extension).  These fixes allow the operators to continue to have DDoW work while the IDR working group to create a second revision of flow specification.

Sue (co-author, WG co-chair). 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Christoph Loibl
Sent: Wednesday, November 4, 2020 9:11 AM
To: Éric Vyncke
Cc: [email-masked]; [email-masked]; [email-masked]; The IESG
Subject: Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Hi Éric,

Cheers Christoph

> ## DISCUSS:
> 
> I am puzzled by the absence of a flow spec for the first Next-Header 
> being a specific value and by the absence of a flowspec for the 
> occurence of any extension header in the extension header chain. 
> Extension headers are an important difference compared to IPv4 and 
> could be 'nasty' as well (e.g., hop-by-hop header). Why was this not 
> considered by the authors ? Or is there another document in the WG to address this issue ?
> 

> ## COMMENT:
> == COMMENTS ==
> 
> -- Section 3.1 --
> Smart idea to have an offset but I wonder whether "Offset < Length < 
> 129" is true... Esp. with some IPv6 addresses with an embedded IPv4 
> address (32 bit) at offset 96. Isn't "Offset + Length <= 128" better ?
> 

> -- Section 3.3 --
> How is the upper-layer defined here? Basically, how a node can 
> determine whether it is an extension header or an upper-layer header? 
> While I agree that there are not too many new upper-layer protocols 
> being specified, I would prefer to have a definition of "upper-layer" 
> here either by listing (or referring to a IANA registry) all existing 
> extension headers (then all 'next header' not being 'extension header' 
> are by default 'upper layer') or vice-versa.

> == NITS ==
> 
> -- Section 3.1 (and possibly others) -- Sometimes the field 'length' 
> is all lower case and sometimes it is capitalized.
> 

> -- Section 3.8.2 (and possibly others) -- Please use RFC 5952 to write 
> IPv6 addresses.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 5 Nov 2020 14:29:30 +0000

Christoph and Robert,

I guess that we all agree that the IPv6 extension header chain is a special “feature” of IPv6 that does not help simplification and is not easy to handle. Nevertheless, I like extension headers as they allow for extensibility of IPv6.

What really puzzles me is that the document assumes that the extension header chain can be parsed until the upper-layer protocol (that is really tough in hardware) but is unable to specify a flow based on the Next-Header field of the IPv6 header (that is trivial from my naïve point of view). So, I would assume if DDoS mitigation devices can do the most complex one (= filter on upper layer) they should also be able to do the simplest one (= filter on Next-Header) or even the medium one (= presence of a specific extension header in the chain).

Again , I appreciate that this is a complex issue but I cannot understand the reasoning of the WG.

Else, look for EV> in the text

Thank you BTW for your quick and detailed reply

Regards

-éric

From: Christoph Loibl <[email-masked]>
Date: Wednesday, 4 November 2020 at 15:11
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Jie Dong <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Hi Éric,

Cheers Christoph

EV> indeed, it looks like I read it too fast and assumed that it was like the substring function in some programming language. My bad obviously, thank you for correcting me. Perhaps worth adding an example before the one in section 3.8.1? I do not remember whether the 5575-bis document has a similar concept (if so, then no need to provide an example even).

This is the term used in RFC8200 for the "last" next-header. It also explains how to detect the upper-layer protocol.
EV> indeed the reference to RFC 8200 (that is already in the doc) is enough. But, now, I have another question: how will the ‘No Next Header’ be specified or processed by the Flow Spec ?

EV> Good idea indeed

EV> and your reply to Ben is fine for me

EV> actually, my comment was not about the /64-104 notation but rather “::1234:5678:9A00:0” that should be written as “::1234:5678:9a00:0” :-) (lower case and no trailing 0) and “2001:db8::/32” (also lowercase)