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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 10:26:58 -0800

Benjamin Kaduk 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:
----------------------------------------------------------------------

A fairly minor point, but I think that allowing Type 13 (flow label)
component values to be encoded as 2-byte quantities encourages the
selection of non-random flow label values, and thus violates the
guidance from RFC 6437 that these values "should be chosen such that
their bits exhibit a high degree of variability" and that "third parties
should be unlikely to be able to guess the next value that a source of
flow labels will choose."  While having the short 1-byte encoding for a
flow label of 0 might be reasonable, a 2-byte label can represent at
most 16 bits of the 20-bit identifier space, discouraging the use of the
high 4 bits, when such bits of unpredictability are scarce already.
Let's discuss how big an issue this is and what might be done to
mitigate it.

Please also confirm that we are providing all the information required of
us by RFC 5701 and 5575bis (see comments on Section 6.1); I am not sure
whether I am reading the references correctly in these regards.

There seems to be an error in the sample code (flow_rule_cmp_v6()): the
snippet
               if comp_a.offset < comp_b.offset:
                   return A_HAS_PRECEDENCE
               if comp_a.offset < comp_b.offset:
                   return B_HAS_PRECEDENCE
duplicates the condition, whereas the condition should be swapped for
correct operation.

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

Thanks for this straightforward and easy-to-read document!  Just a few
minor comments.

Section 3.3

   This component uses the Numeric Operator (numeric_op) described in
   [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1.  Type 3 component values
   SHOULD be encoded as single octet (numeric_op len=00).

Why only SHOULD?  (Likewise for Section 3.4, 3.5, etc.)

Section 3.7

   Contains a list of {numeric_op, value} pairs that are used to match
   the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3).

[It seems that RFC 8200 §3 just points to RFC 8200 §6, which itself
mostly points to RFC 6437.  I don't know if it is useful to
short-circuit some of those references.]

Section 3.8.1

   The following example demonstrates the prefix encoding for: "packets
   from ::1234:5678:9A00:0/64-104 to 2001:DB8::/32 and upper-layer-

Where is the "/64-104" notation introduced?  I did not see it in RFC
4291.  (It also appears in §3.8.2, though the latter uses "/65-104"
to demonstrate the operation of padding.)

Section 4

   The definition for the order of traffic filtering rules from
   [I-D.ietf-idr-rfc5575bis] Section 5.1 is reused with new
   consideration for the IPv6 prefix offset.  As long as the offsets are
   equal, the comparison is the same, retaining longest-prefix-match
   semantics.  If the offsets are not equal, the lowest offset has
   precedence, as this flow matches the most significant bit.

I will note just to confirm my understanding that this procedure seems
to give higher precedence to, e.g., 1234::/1-4 than to
::1234:5678:9a00/81-128 even though the latter is inspecting more bits
of the address/prefix.  (To be clear, some choice has to be made and I
have no reason to prefer a different one over this one, I am just
exploring the consequences of this choice.)

It is again (as per 5575bis) surprising that we allow for a "not-equal"
comparison of differently encoded (e.g., flow label) values that have
the same semantic meaning, but I expect the same response (and no
document change) as when I made the comment the first time.

Section 5

   The validation procedure is the same as specified in
   [I-D.ietf-idr-rfc5575bis] Section 6 with the exception that item a)
   of the validation procedure should now read as follows:

Are there also any AFI/SAFI differences from 5575bis to consider in
terms of "routes received over"/etc.?

Section 6.1

   This extended community uses the same encoding as the IPv6 address
   specific Route Target extended community [RFC5701] Section 2 with the
   high-order octet of the Type always set to 0x80 and the Sub-Type
   always TBD.

RFC 5701 suggests that since we are allocating the "TBD" sub-type value,
we should also state what the semantics of the "local administrator"
2-octet field are.

   Interferes with: All BGP Flow Specification redirect Traffic
   Filtering Actions (with itself and those specified in
   [I-D.ietf-idr-rfc5575bis] Section 7.4).

I think we are supposed to also state what action to take when
encountering interfering actions.

Section 7

It was a little surprising to me that the inability to match (e.g.) TCP
flags or Port values on non-initial IP fragments was not reiterated in
the security considerations of 5575bis.  I don't think it would make
sense to mention that just in this document's security considerations,
though -- if we are to change anything it should be in 5575bis.  But I
guess we had that conversation already, at
https://mailarchive.ietf.org/arch/msg/idr/zvpLPjllvKWFuyraZUVz8lB8Wz0/
and thus no change is expected.

Section 8.1.2

(side note) it seems a little weird to have the IPv4 version be the one
that gets the unqualified (e.g., "Destination Prefix") name.

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 4 Nov 2020 12:41:13 +0100

Hi Benjamin,

Thanks for your review of the document. I have edited the document and I think cleared your discuss with the changes (please see my comments inline). 

Since I have a few more changes to apply the new version is not yet online (however I attached the modified version to this message). Since the draft submission is closed now I will ask Alvaro to publish the changed document today.

Cheers  Christoph

> ## DISCUSS:

The Type-13 component is not the flow label itself. It is only the filter that allows to match on that particular field in the IPv6 header of the packets. If the flow-label encoded in the packet (unlikely, but possible) can be encoded in 8,16-bits one could encode the match filter in a shorter form. However, this may be very unlikely. This specification does not choose those flow labels, but allows to match on flow labels in packets (usually generated by other systems).   

> whether I am reading the references correctly in these regards.

We added the definition of the Local Administrator Field in the Extended community to be aligned with the IPv4 rt community:

ADDED:
       The Local Administrator sub-field contains a number from a numbering
          space that is administered by the organization to which the IP
          address carried in the Global Administrator sub-field has been
          assigned by an appropriate authority. 

> duplicates the condition, whereas the condition should be swapped for

This in fact is a problem in the code that has been corrected, and a test has been added.

> ## COMMENT:

This is because we want these types to be aligned with the IPv4 types as much as possible in order to allow for reusable code.

> short-circuit some of those references.]
 
Flow Spec does not care about what and how this Flow Label is actually encoded. It matches against this particular 20-bit field in the header. I think it is better to keep this reference.

> from :🔢5678:9A00:0/64-104 to 2001:DB8::/32 and upper-layer-
> 

Appended this to the Type-1 compontent section:

   Note: This Flow Specification component can be represented by the
   notation ipv6address/length if offset is 0, or ipv6address/offset-
   length.  The ipv6address in this notation is the textual IPv6
   representation of the pattern shifted to the right by the number of
   offset bits.  See also Section 3.8.

> :🔢5678:9a00/81-128 even though the latter is inspecting more bits

Yes this is the case. In general the lower offset generates a lower number of consecutive IPv6 address blocks that would match (offset=0 matches IP addresses only from a single prefix, offset=1 matches 2 blocks, offset=2 4, ...), this can be extended to offset=127 which matches every second IPv6 address. 
 
> document change) as when I made the comment the first time.

While we add IPv6 functionality into Flow-Spec (rfc5575bis) changing any of the fundamental behaviour is out of the scope of this document. 

> terms of "routes received over"/etc.?

Flow-Spec V6 uses a different AFI/SAFI but this is already covered in the rfc5575bis text when it comes to validation:

   The validation process described below validates Flow Specifications
   against unicast routes received over the same AFI but the associated

> we should also state what the semantics of the "local administrator"

This has been edited into the document. See also the DISCUSS section.

> encountering interfering actions.

This is already in rfc5575bis Section 7.7, and also applies to this document.

> and thus no change is expected.

While IPv4 and IPv6 fragmentation serves the same pupose the encoding is different so we needed to redefine thi section. FS is working stateless on the packets and can only match on what is in the packet.

I cannot access the url from above.

> that gets the unqualified (e.g., "Destination Prefix") name.

This is because we are not changing names of rfc5575bis to avoid confusion.

-- 
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:17:22 -0500

Ben:

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 6:41:43 AM, Christoph Loibl ([email-masked]) wrote:

Since I have a few more changes to apply the new version is not yet online
(however I attached the modified version to this message). Since the draft
submission is closed now I will ask Alvaro to publish the changed document
today.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Nov 2020 08:36:19 -0800

Hi Christoph,

> Thanks for your review of the document. I have edited the document and I think cleared your discuss with the changes (please see my comments inline). 

Also inline, though I will not specifically comment on the (many) bits that
look good as-is.

> The Type-13 component is not the flow label itself. It is only the filter that allows to match on that particular field in the IPv6 header of the packets. If the flow-label encoded in the packet (u…

I understand that this specification is describing patterns to match flow
labels and not the flow labels themselves, yes.  However, this document is
saying that, *if* the flow labels themselves have a certain structure, then
the flow specification (from this document) to match the flow labels has a
more compact encoding.  This, in turn, sets up an incentive for the party
assigning flow labels to conform to the specific structure of flow label
values, in order to take advantage of the more compact encoding.  I believe
that using any kind of substructure when assigning flow label values is
contrary to the guidance of RFC 6437 (and, relately, harms the overall
security of the internet), and thus am supplying resistance to a mechanism
that incentivizes using such internal structure in flow label values.
The discussion that I would like to have here relates to the magnitude of
incentive in question (to use specific substructure when generating flow
label values), which in turn is related to how much benefit there is from
shaving two bytes off the flow specification encoding.  I do not believe
that your comment above is trying to make such an assessment on the
magnitude of the incentive in question or the value of having the slightly
more compact encoding available.

> This in fact is a problem in the code that has been corrected, and a test has been added.

I am happy to hear that a test has been added in addition to fixing the
bug.

> This is because we want these types to be aligned with the IPv4 types as much as possible in order to allow for reusable code.

Ah, of course.  I should have checked that before commenting; sorry.

Thanks!

>    unicast routing information SAFI:

Thank you for the extra explanation; I suspected that there was something
like this that I was missing.

> While IPv4 and IPv6 fragmentation serves the same pupose the encoding is different so we needed to redefine thi section. FS is working stateless on the packets and can only match on what is in the…

Exactly.  I am proposing that this restriction (working stateless and
cannot match [application-layer headers] things not in the packet) is
mentioned again in the security considerations section.  I believe that
this limitation can be described in a way that is agnostic to IPv4 vs IPv6,
and thus would be better placed in 5575bis than in this document.

> I cannot access the url from above.

Huh, interesting.  Perhaps if you log in with your datatracker credentials?
I had specifically tried to find one in the idr archive, since the iesg
archive is definitely non-public.
The referred-to message is "Re: [Idr] Benjamin Kaduk's Discuss on
draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT)" from  Fri, 24
April 2020 02:12 UTC, Message-ID: <[email-masked]>.

Thanks again,

Ben

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 4 Nov 2020 21:33:56 +0100

Hi Benjamin,

See my comments below (I stripped down the message, it only contains the remaining issues). 

@ Alvaro: Please also read my last question.

> On 04.11.2020, at 17:36, Benjamin Kaduk <[email-masked]> wrote:
>>> ## DISCUSS:

I do not think that is an incentive for anyone. The main application for FS is DDoS mitigation. Those who mitigate an attack with FS do not even have control over the flow-labels used by an attack. One could argue that for an attacker it could be even an advantage to make use of the entire 20-bit flow-label space to make mitigation via FS less efficient (but this might be a bit exaggerated). 

> and thus would be better placed in 5575bis than in this document.

I agree that this should rather go into 5575bis than in this document. 

I suggest to add the following to the Security Considerations section: 

ADD: 
Implementations may not be able to locate all header values
required to identify a packet. This can be especially problematic 
in the case of fragmented packets that are not the first fragment 
and thus lack upper-layer protocol headers or Encapsulating Security 
Payload (ESP) NULL [RFC4303] encryption.

@ Alvaro do you think we should roll that paragraph into rfc5575bis?

Cheers Christoph

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 4 Nov 2020 12:56:52 -0800

Hi!

Yes, if that text works for Ben then we can still add it to rfc5575bis.

Thanks!

Alvaro.

On November 4, 2020 at 3:34:36 PM, Christoph Loibl ([email-masked]) wrote:

Hi Benjamin,

See my comments below (I stripped down the message, it only contains the
remaining issues).

...

>> While IPv4 and IPv6 fragmentation serves the same pupose the encoding is
different so we needed to redefine thi section. FS is working stateless on
the packets and can only match on what is in the packet.

ADD:

Cheers Christoph

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Nov 2020 19:43:26 -0500

Christoph and Ben: 

I think we should roll the paragraph into RFC5575 if Alvaro and Ben think it
helps.  I believe that DDoS implementers show know that concept, but it
never hurts to repeat security issues. 

The discussion on the IDR list for v6 did not deal with this specific issue
Ben is raising.  I also agree with Christoph's point that for DDoS
implementations, I do not see the incentive.  

Ben - is there some operational example you can provide for the DDoS event.

Sue

-----Original Message-----
From: Christoph Loibl [mailto:[email-masked]] 
Sent: Wednesday, November 4, 2020 3:34 PM
To: Benjamin Kaduk
Cc: The IESG; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [BULK] [Idr] Benjamin Kaduk's Discuss on
draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Hi Benjamin,

>>> their bits exhibit a high degree of variability" and that "third 
>>> parties should be unlikely to be able to guess the next value that a 
>>> source of flow labels will choose." While having the short 1-byte 
>>> encoding for a flow label of 0 might be reasonable, a 2-byte label 
>>> can represent at most 16 bits of the 20-bit identifier space, 
>>> discouraging the use of the high 4 bits, when such bits of
unpredictability are scarce already.
>> The Type-13 component is not the flow label itself. It is only the filter
that allows to match on that particular field in the IPv6 header of the
packets. If the flow-label encoded in the packet (unlikely, but possible)
can be encoded in 8,16-bits one could encode the match filter in a shorter
form. However, this may be very unlikely. This specification does not choose
those flow labels, but allows to match on flow labels in packets (usually
generated by other systems).   
> 
> I understand that this specification is describing patterns to match 
> flow labels and not the flow labels themselves, yes.  However, this 
> document is saying that, *if* the flow labels themselves have a 
> certain structure, then the flow specification (from this document) to 
> match the flow labels has a more compact encoding.  This, in turn, 
> sets up an incentive for the party assigning flow labels to conform to 
> the specific structure of flow label values, in order to take 
> advantage of the more compact encoding.  I believe that using any kind 
> of substructure when assigning flow label values is contrary to the 
> guidance of RFC 6437 (and, relately, harms the overall security of the 
> internet), and thus am supplying resistance to a mechanism that
incentivizes using such internal structure in flow label values.
> The discussion that I would like to have here relates to the magnitude 
> of incentive in question (to use specific substructure when generating 
> flow label values), which in turn is related to how much benefit there 
> is from shaving two bytes off the flow specification encoding.  I do 
> not believe that your comment above is trying to make such an 
> assessment on the magnitude of the incentive in question or the value 
> of having the slightly more compact encoding available.

I do not think that is an incentive for anyone. The main application for FS
is DDoS mitigation. Those who mitigate an attack with FS do not even have
control over the flow-labels used by an attack. One could argue that for an
attacker it could be even an advantage to make use of the entire 20-bit
flow-label space to make mitigation via FS less efficient (but this might be
a bit exaggerated). 

>>> 
>>> Section 7
>>> 
>>> It was a little surprising to me that the inability to match (e.g.) 
>>> TCP flags or Port values on non-initial IP fragments was not 
>>> reiterated in the security considerations of 5575bis. I don't think 
>>> it would make sense to mention that just in this document's security 
>>> considerations, though -- if we are to change anything it should be 
>>> in 5575bis. But I guess we had that conversation already, at 
> mentioned again in the security considerations section.  I believe 
> that this limitation can be described in a way that is agnostic to 
> IPv4 vs IPv6, and thus would be better placed in 5575bis than in this
document.

ADD: 
Implementations may not be able to locate all header values required to
identify a packet. This can be especially problematic in the case of
fragmented packets that are not the first fragment and thus lack upper-layer
protocol headers or Encapsulating Security Payload (ESP) NULL [RFC4303]
encryption.

Cheers Christoph

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Nov 2020 13:25:44 -0800

Hi Christoph, Sue,

> I do not think that is an incentive for anyone. The main application for FS is DDoS mitigation. Those who mitigate an attack with FS do not even have control over the flow-labels used by an attack.…

Thanks for the extra context; I was assuming there were "normal traffic
management" cases as well as DDoS mitigation ones.

That would make me want to flip my question around, then -- what is gained
by encoding the flow spec filter for flow labels in 8 or 16 bits instead of
32?  I am not trying to say that it must always be in 32, especially if the
WG definitely wants to allow those cases.  It just seems like it might be
simpler to always use the 32-bit encoding and avoid having to deal with the
case where the value in the filter has to match a wider field in the actual
IP header.

To attempt to answer Sue's question: I don't have a particular DDoS case in
mind where this is relevant (and I would mostly assume that an extra byte
or two in the flowspec encoding would be in the noise).  I was just trying
to understand the reasoning for having the flexibility of the shorter
encoding, since using the shorter encoding introduces other issues.

> @ Alvaro do you think we should roll that paragraph into rfc5575bis?

I'm happy to see that or something like it in 5575bis; thanks!
I am not sure, though, of the intended grouping -- is the ESP NULL
encryption case intended to be one of the "especially problematic" cases,
or something that is absent in fragmented packets?  I assume the former, in
which case this version might be easier to read:

% Implementations may not be able to locate all header values
% required to identify a packet. This can be especially problematic 
% in the case of fragmented packets that are not the first fragment and
% thus lack upper-layer protocol headers, or when Encapsulating Security
% Payload (ESP) NULL [RFC4303] encryption is used.

Thanks again!

-Ben

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Nov 2020 00:01:32 +0100

Hi,

For the record of part of this discussion regarding size of flowspec v6
flow label field I am perfectly ok to have it fixed size of 20 bit field.

As a matter of fact if we assume that flow label allocation nature is to be
dynamic by IETF recommendation I am also perfectly fine to remove flow
label match from flow spec v6 all together.

Kind regards,
Robert.

On Wed, Nov 4, 2020 at 5:36 PM Benjamin Kaduk <[email-masked]> wrote:

> > Thanks for your review of the document. I have edited the document and I
> think cleared your discuss with the changes (please see my comments
> inline).
>
> > Since I have a few more changes to apply the new version is not yet
> online (however I attached the modified version to this message). Since the
> draft submission is closed now I will ask Alvaro to publish the changed
> document today.
> >
> > Cheers  Christoph
> >
> >
> > > ## DISCUSS:
> parties
> > The Type-13 component is not the flow label itself. It is only the
> filter that allows to match on that particular field in the IPv6 header of
> the packets. If the flow-label encoded in the packet (unlikely, but
> possible) can be encoded in 8,16-bits one could encode the match filter in
> a shorter form. However, this may be very unlikely. This specification does
> not choose those flow labels, but allows to match on flow labels in packets
> (usually generated by other systems).
>
> > We added the definition of the Local Administrator Field in the Extended
> community to be aligned with the IPv4 rt community:
> >
> > ADDED:
> > This is because we want these types to be aligned with the IPv4 types as
> much as possible in order to allow for reusable code.
>
> > Flow Spec does not care about what and how this Flow Label is actually
> encoded. It matches against this particular 20-bit field in the header. I
> think it is better to keep this reference.
> >
> > > Section 3.8.1
> > >
> > Yes this is the case. In general the lower offset generates a lower
> number of consecutive IPv6 address blocks that would match (offset=0
> matches IP addresses only from a single prefix, offset=1 matches 2 blocks,
> offset=2 4, ...), this can be extended to offset=127 which matches every
> second IPv6 address.
> >
> > While we add IPv6 functionality into Flow-Spec (rfc5575bis) changing any
> of the fundamental behaviour is out of the scope of this document.
> >
> > > Section 5
> > >
> > Flow-Spec V6 uses a different AFI/SAFI but this is already covered in
> the rfc5575bis text when it comes to validation:
> >

---

From: Erik Kline <[email-masked]>
Date: Fri, 6 Nov 2020 16:02:21 -0800

FWIW, I had assumed that the 1/2/4 byte formats were for encoding the
non-zero parts of a flow label, i.e. flowlabels 1-255 could fit in 1 byte,
256-65535 in 2 bytes, and everything else up to 2^20-1 in 4 bytes.

If that's true, it seemed reasonable to me.  Also reasonable, I would
think, is to just specify, say, a fixed 3 byte unsigned int.

I think it would be valuable to keep the flow label matching functionality,
not least because it can be used to group into a flow the fragments where
the upper layer header info is not present.

On Fri, Nov 6, 2020 at 3:01 PM Robert Raszuk <[email-masked]> wrote:

> As a matter of fact if we assume that flow label allocation nature is to
> be dynamic by IETF recommendation I am also perfectly fine to remove flow
>> > Thanks for your review of the document. I have edited the document and
>> I think cleared your discuss with the changes (please see my comments
>> inline).
>>
>> > We added the definition of the Local Administrator Field in the
>> Extended community to be aligned with the IPv4 rt community:
>> >
>> > ADDED:
>> > This is because we want these types to be aligned with the IPv4 types
>> as much as possible in order to allow for reusable code.
>>
>> > While we add IPv6 functionality into Flow-Spec (rfc5575bis) changing
>> any of the fundamental behaviour is out of the scope of this document.
>> >
>> > > Section 5
>> > >
>> TCP
>> > While IPv4 and IPv6 fragmentation serves the same pupose the encoding
>> is different so we needed to redefine thi section. FS is working stateless
>> on the packets and can only match on what is in the packet.
>>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Nov 2020 12:45:09 +0100

Ok 3 octets to keep byte boundary sounds reasonable indeed.

> to keep the flow label matching functionality

On that point I have a mixed feelings.

On one hand original thought for adding this into flow-spec was based on
manual setting of flow-labels.

Now if that setting is recommended to be automated and random I am really
afraid that any attempt to retrieve flow label values and to signal them
with BGP FS may result in massive burden to BGP - at any given time there
can be millions of flows. Leave alone dynamic nature of those short lived
flows.

Then even if BGP can signal it, RRs can propagate it then the attempt to
install such number of ACLs into FS receiver's data plane will either fail
or the box will crash.

Cheers,
R.

On Sat, Nov 7, 2020 at 1:02 AM Erik Kline <[email-masked]> wrote:

> I think it would be valuable to keep the flow label matching
> functionality, not least because it can be used to group into a flow the
> fragments where the upper layer header info is not present.
>
>>> April 2020 02:12 UTC, Message-ID: <[email-masked]
>>> >.
>>>
>>> Thanks again,
>>>
>>> Ben
>>>
>>> > >
>>> > > Section 8.1.2
>>> > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 8 Nov 2020 20:32:10 -0800

> Ok 3 octets to keep byte boundary sounds reasonable indeed.

Well, the
https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-27#section-4.2.1.1
'len' encoding options don't give a 3-byte option for the value field.
Which is why I was assuming 4-bytes.

-Ben

---

From: Erik Kline <[email-masked]>
Date: Sun, 8 Nov 2020 20:35:19 -0800

Whether randomized or not, I would imagine the use of flow label matching
would be more the exception than the rule.

On Sat, Nov 7, 2020 at 3:45 AM Robert Raszuk <[email-masked]> wrote:

>>>> > Thanks for your review of the document. I have edited the document
>>>> and I think cleared your discuss with the changes (please see my comments
>>>> inline).
>>>>
>>>> flow
>>>> of
>>>> > Flow Spec does not care about what and how this Flow Label is
>>>> actually encoded. It matches against this particular 20-bit field in the
>>>> header. I think it is better to keep this reference.
>>>> >
>>>> > > Section 3.8.1
>>>> > >

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 9 Nov 2020 12:05:09 +0100

Hi,

I am reading thru the discussion and trying to summarize + my comments:

> On 09.11.2020, at 05:35, Erik Kline <[email-masked]> wrote:
> Whether randomized or not, I would imagine the use of flow label matching would be more the exception than the rule.

ack.

> On 09.11.2020, at 05:32, Benjamin Kaduk <[email-masked]> wrote:
> 

Correct, if we want a 3 octets (or 20-bits) length we need to “re-invent the wheel” = we need to add a new “operator” that supports 3-byte length etc. Not only the document needs to extended, but also implementations need to take care of yet another operator encoding format. 

We can however easily require the length of the flow-label field to be 4-octets:

	Type 13 component values MUST be encoded as 4-octet quantity 
        (numeric_op len=10).

But this is an exception because we usually use SHOULD there in rfc5575bis (only because of historical incompatibilities that could not be changed in the -bis though), and I am not sure if adding this special case really makes it better (since it does not reduce complexity).

How can we continue?

Cheers 

Christoph

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Nov 2020 12:58:05 -0800

> Correct, if we want a 3 octets (or 20-bits) length we need to “re-invent the wheel” = we need to add a new “operator” that supports 3-byte length etc. Not only the document needs to extended, but a…

Exactly, and that is (IMO clearly) something for flowspec v2 if at all, not
this document.

> But this is an exception because we usually use SHOULD there in rfc5575bis (only because of historical incompatibilities that could not be changed in the -bis though), and I am not sure if adding t…

There do seem to be a couple "MUST"s as well (but maybe just for fields
that are smaller than 1 octet or flags, so the reasoning is a little
different than for the case we're looking at).  I don't think this issue is
significant enough that we need to diverge from 5575bis (and 5575 itself),
though, and I do see what you mean about "SHOULD" being most common.

> How can we continue?

I think it would be okay to just drop the specific mention of 1- and 2-byte
encoding for the flow label match, so we have "[t]ype 13 component values
SHOULD be encoded as 4-byte quantities (len=10)".

I'm of course happy to hear other suggestions as well!

Thanks,

Ben

---

From: Christoph Loibl <[email-masked]>
Date: Fri, 13 Nov 2020 08:25:35 +0100

Hi Benjamin,

Since I did not see any objections on the list I edited this as suggested into the document:

   This component uses the Numeric Operator (numeric_op) described in
   [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1.  Type 13 component values
   SHOULD be encoded as 4-octet quantities (numeric_op len=10).

Cheers

Christoph

> On 09.11.2020, at 21:58, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Nov 2020 03:09:01 -0500

Ben,

> SHOULD be encoded as 4-byte quantities (len=10)".

I will note that Juniper's implementation simply goes for best-fit for any
given value.  While the SHOULD for 4-byte sizing won't make us
non-conformant, it's not what we do.  E.g. a value that can fit into one
byte will use that length.

Given the general encoding of lengths in the base flowspec document, you can
insist on whatever size you want for the SHOULD of the size to send, but
receivers need to follow Postel's maxim on receipt.

-- Jeff

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 15 Nov 2020 23:57:56 -0800

> receivers need to follow Postel's maxim on receipt.

I agree.

Thanks for commenting,

Ben

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 16 Nov 2020 10:12:18 +0100

Hi,

While I (personally) would prefer something like Juniper’s implementation. rfc5575bis's consensus was the approach that we suggest an encoding length for each FS component. The current approach in flow-spec-v6 does not break this concept and is consistent also with the base FS document. As Jeffrey mentioned it is also compatible with the “use as less bits as possible” encoding approach. Thanks for the comment Jeffrey. 

I will upload a -20 today. This will fix all the nits and comments from the IESG review process.

Cheers 

Christoph 

> On 16.11.2020, at 08:57, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Nov 2020 04:42:49 -0500

> While I (personally) would prefer something like Juniper’s implementation. rfc5575bis's consensus was the approach that we suggest an encoding length for each FS component. The current approach in…

Remind me, is there procedure handling improper values for the length of the
component semantics?

E.g. ports can only be 2 bytes of value. 

I have a feeling this is in the base procedures of "this can't match, so
it's not a problem" but I'm not finding it right now.

-- Jeff

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 16 Nov 2020 10:59:15 +0100

Hi,

> On 16.11.2020, at 10:42, Jeffrey Haas <[email-masked]> wrote:
> 

In case of the port component, the numeric operator does lt, gt, eq comparisons between the port in the packet and the value followed by the operator. This is independent on the encoding. Only that the port can never exceed the 16bit boundary. While the value from the operator technically can and will, depending on the operator (gt,lt,eq), even match packets. 

Cheers Christoph

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Nov 2020 11:12:48 +0100

Hi,

I think Jeff is asking what if the length in numeric-op is different then
"10" meaning 4 octets say it is sent with "01"?

"Type 13 component values SHOULD be encoded as 4-octet quantities
(numeric_op len=10)."

It seems this is exactly what his implementation will do today.

It looks to me on the surface as this "SHOULD" is while not a MUST it still
does not allow flexibility to send only what is needed as it was seen as
encouraging manual flow label allocation.

So with current text I am not sure if some implementations may not claim
RFC violation when they see Junos sending shorter numeric_op length.

Thx,
R.

On Mon, Nov 16, 2020 at 10:59 AM Christoph Loibl <[email-masked]> wrote:

> In case of the port component, the numeric operator does lt, gt, eq
> comparisons between the port in the packet and the value followed by the
> operator. This is independent on the encoding. Only that the port can never
> exceed the 16bit boundary. While the value from the operator technically
> can and will, depending on the operator (gt,lt,eq), even match packets.
>
> Cheers Christoph
>
> --
> Christoph Loibl

---

From: John Scudder <[email-masked]>
Date: Mon, 16 Nov 2020 20:17:28 +0000

Hi All,

> On Nov 16, 2020, at 4:42 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 

FYI I’ve started a discussion with the 5575bis authors just to be sure there isn’t some text we need to tighten up there, since it’s not published yet.

Thanks,

—John