Subject: Re: [sfc] A problem with NSH TLV

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 12 Jul 2016 00:04:30 +0000

This is not really a new problem and hopefully we can leverage widely used solutions.  IPfix for example also relies on TLVs and has encodings for octets strings, binary and all other formats known to man.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] A problem with NSH TLV

Ron,
I agree your solution to use bits 25-26 to indicate padding would be backwards compatible if anyone is concerned about backwards compatibility.
I'd be OK with that.

-Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: A problem with NSH TLV

Hi, Dave.

I agree that valid length must be indicated even when not a multiple of 4 octets and agree with your solution.   A description of alignment within the 4 octets should be part of the text, as well - fields whose lengths are not multiples of 4 are "left justified" towards the lower octet numbers with zero-value padding inserted at the higher octet numbers.

Do you think this is justification to bump the version number of the NSH, since implementations are already fielded?    In v0, the length is interpreted as a 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.

If the community is opposed to bumping the version, another approach would be to use bits 25 and 26 as a pad-length field.  Bits 27-31 would continue to be length in 4-octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (values 0..3).

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] A problem with NSH TLV

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

This is the TLV format:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Metadata Class       |C|    Type     |R|R|R|   Len   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Variable Metadata                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Len is defined as number of 4-byte words.
The problem with this is that strings aren't always multiples of 4 bytes in length.

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is given:

   10.  Universal Resource Identifier (URI)

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         TLV Class = 0x0       |C|    Type=0xA |R|R|R|   L=var |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |UT(4)  |                URI                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        URI                                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Despite the confusing part about the first nybble being used for UT field (supposed to be an octet?),
if the URI is not a multiple of 4 bytes, how is it to be terminated?

Diameter (RFC6733) solves this problem nicely by making the length indicate a number of octets, while specifying padding to 4-octet alignment for the next element.

So my proposal is to recruit two of the 'R' bits into the 'L' field, and have it indicate number of octets; and also say that padding is to be inserted so that each TLV is a multiple of 4 octets in length.

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: Dave Dolson <[email-masked]>
Date: Tue, 12 Jul 2016 16:51:39 +0000

(Informal survey of the binary formats I could think of)

---------
IPFix uses Field Length of octets for the Field Specifier, but also made a bit of a mess of variable-length fields, IMO:
https://tools.ietf.org/html/rfc7011#section-7

   In the Template Set, the Information Element Field Length is recorded
   as 65535.  This reserved length value notifies the Collecting Process
   that the length value of the Information Element will be carried in
   the Information Element content itself.
...
I don't see the point of that unless it comes from some legacy. Why waste bytes in the information element when length could have been placed in the length field?

----------
Diameter (RFC 6733) AVPs have a length field in octets that includes the AVP header. Note the format requires padding if the length is not a multiple of 4.

   OctetString

      The data contains arbitrary data of variable length.  Unless
      otherwise noted, the AVP Length field MUST be set to at least 8
      (12 if the 'V' bit is enabled).  AVP values of this type that are
      not a multiple of 4 octets in length are followed by the necessary
      padding so that the next AVP (if any) will start on a 32-bit
      boundary.

---------
CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -text string, "the length gives the number of bytes"

----------
ASN.1 - although there are different ways of encoding the length, the value of length field indicates number of octets.

--------
XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in bytes, with padding to multiple of 4:

4.10.  Variable-Length Opaque Data

   The standard also provides for variable-length (counted) opaque data,
   defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
   to be the number n encoded as an unsigned integer (as described
   below), and followed by the n bytes of the sequence.

   Byte m of the sequence always precedes byte m+1 of the sequence, and
   byte 0 of the sequence always follows the sequence's length (count).
   If n is not a multiple of four, then the n bytes are followed by
   enough (0 to 3) residual zero bytes, r, to make the total byte count
   a multiple of four...

-------
I'm not aware of any formats in which variable-length string fields are encoded with number of words vs. number of octets.

I recommend the length field is the number of octets of the data (not including the header), with 0 as a valid value representing the empty string.
Some implementers may prefer to have padding to 4-byte alignment.

But I wouldn't like to see the IPFix approach.

-Dave

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; [email-masked]
Subject: Re: [sfc] A problem with NSH TLV

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Jul 2016 17:04:08 +0000

Hi, Dave.

I agree that length in octets, excluding header, is the right way to go.   This includes your proposed expansion of the length field by 2 bits.   I also suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and "justification" of small native bytes towards the lower numbered bytes with padding at the higher numbered bytes.

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]
Subject: RE: [sfc] A problem with NSH TLV

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] A problem with NSH TLV

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Tue, 12 Jul 2016 17:19:30 +0000

Agreed, padding should be at the end of the string. (If I understood correctly.)

E.g., encoding of octet string{0x31 0xff 0x00 0x21 0x00}:

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          TLV Class            |C|    Type     |R|    Len=5    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    0x31       |   0xff        |    0x00       |    0x21       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    0x00       |      X        |        X      |       X       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

X means "don't care". We could say "should be 0"

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 1:04 PM
To: Dave Dolson; Reinaldo Penno (repenno); [email-masked]
Subject: RE: [sfc] A problem with NSH TLV

Hi, Dave.

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>>; Ron Parker <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] A problem with NSH TLV

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: <[email-masked]>
Date: Wed, 13 Jul 2016 13:44:49 +0000

Hi Dave,

I agree with your proposal: "length field is the number of octets of the data".

FWIW, this is one of the pending issues raised during the WGLC (see: https://www.ietf.org/mail-archive/web/sfc/current/msg04522.html).

For the record, Stewart and Azhar raised a point whether 256 bytes is sufficient. If there is really a need to define large context elements, I suggested an idea that is close to the TCP scaling window: use one of the reserved bits to shift the length by a number that the WG will agrees on (scale factor bit).

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : mardi 12 juillet 2016 18:52
À : Reinaldo Penno (repenno); Ron Parker; [email-masked]
Objet : Re: [sfc] A problem with NSH TLV

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Wed, 13 Jul 2016 14:57:20 +0000

I assume you mean 255 (not 256) would be the limit.
For data that is added to packets that might already be 1500 bytes in size, this would seem to be a sensible limit.
What use-case would require larger?

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; [email-masked]
Subject: RE: [sfc] A problem with NSH TLV

Hi Dave,

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : mardi 12 juillet 2016 18:52
À : Reinaldo Penno (repenno); Ron Parker; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] A problem with NSH TLV

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Wed, 13 Jul 2016 15:09:58 +0000

I agree.   We are talking about "inband" augmentation of packets and not "out-of-band" reporting.

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 10:57 AM
To: [email-masked]; Reinaldo Penno (repenno) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]
Subject: RE: [sfc] A problem with NSH TLV

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] A problem with NSH TLV

Hi Dave,

Cheers,
Med

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: <[email-masked]>
Date: Wed, 13 Jul 2016 15:12:32 +0000

Re-,

Please see inline.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : mercredi 13 juillet 2016 16:57
À : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Ron Parker; [email-masked]
Objet : RE: [sfc] A problem with NSH TLV

I assume you mean 255 (not 256) would be the limit.
[Med] I meant the max is 2^^8 bytes (8 bits to encode the length).
For data that is added to packets that might already be 1500 bytes in size, this would seem to be a sensible limit.

What use-case would require larger?
[Med] I'm not convinced there is a need for such large elements, but Stewart mentioned this case: "So, the question becomes, might you need to use more than 256 bytes in describing why you sent a packet somewhere, and I suspect that you might, for example if you needed to provide the rule set for the selection of the packet.".

Hi Dave,

Cheers,
Med

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 13 Jul 2016 17:11:48 +0000

I suggest we say it “must be” null character.  It will help detect any parsing problems, buffer overrun attacks, etc.

From: Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 12, 2016 at 2:19 PM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] A problem with NSH TLV

      0                   1                   2                   3

X means “don’t care”. We could say “should be 0”

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 1:04 PM
To: Dave Dolson; Reinaldo Penno (repenno); [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] A problem with NSH TLV

Hi, Dave.

I agree that length in octets, excluding header, is the right way to go.   This includes your proposed expansion of the length field by 2 bits.   I also suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and “justification” of small native bytes towards the lower numbered bytes with padding at the higher numbered bytes.

   Ron

---------

…
I don’t see the point of that unless it comes from some legacy. Why waste bytes in the information element when length could have been placed in the length field?

----------

   OctetString

---------
CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -text string, “the length gives the number of bytes”

----------

--------

-------
I’m not aware of any formats in which variable-length string fields are encoded with number of words vs. number of octets.

But I wouldn’t like to see the IPFix approach.

-Dave

Ron,
I’d be OK with that.

-Dave

Hi, Dave.

I agree that valid length must be indicated even when not a multiple of 4 octets and agree with your solution.   A description of alignment within the 4 octets should be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards the lower octet numbers with zero-value padding inserted at the higher octet numbers.

   Ron

This is the TLV format:
        0                   1                   2                   3

Len is defined as number of 4-byte words.
The problem with this is that strings aren’t always multiples of 4 bytes in length.

So my proposal is to recruit two of the ‘R’ bits into the ‘L’ field, and have it indicate number of octets; and also say that padding is to be inserted so that each TLV is a multiple of 4 octets in length.

David Dolson

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 13 Jul 2016 17:16:26 +0000

I’m with Med that if you need more than 256 then you should switch to an out of band protocol. I’m sure somebody might dig up some fringe  use-case for more than 256 but at the same time it seems defeating the purpose of a high-speed, in-band exchange of data.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 13, 2016 at 12:12 PM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] A problem with NSH TLV

Re-,

Please see inline.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : mercredi 13 juillet 2016 16:57
À : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Ron Parker; [email-masked]<mailto:[email-masked]>
Objet : RE: [sfc] A problem with NSH TLV

What use-case would require larger?
[Med] I’m not convinced there is a need for such large elements, but Stewart mentioned this case: “So, the question becomes, might you need to use more than 256 bytes in describing why you sent a packet somewhere, and I suspect that you might, for example if you needed to provide the rule set for the selection of the packet.”.

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] A problem with NSH TLV

Hi Dave,

I agree with your proposal: “length field is the number of octets of the data”.

Cheers,
Med

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 13 Jul 2016 17:18:47 +0000

Sorry if this question was answered. But why not just pad everything to 4 byte boundaries (binary and strings)?  Everything is transmitted in network order, we should have no problems, right? No?

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 12, 2016 at 2:04 PM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] A problem with NSH TLV

Hi, Dave.

   Ron

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Wed, 13 Jul 2016 17:20:44 +0000

Reinaldo,
How does that help with buffer overrun attacks?

Certainly the receiver should never trust that there is a null at the end.

And also, a string that is a multiple of 4 would not need to have a null at the end.

To help against attacks, it might be better to specify, "should be filled with random numbers" so that assumptions in receiving code are caught quickly.

-Dave

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 1:12 PM
To: Dave Dolson; Ron Parker; [email-masked]
Subject: Re: [sfc] A problem with NSH TLV

I suggest we say it "must be" null character.  It will help detect any parsing problems, buffer overrun attacks, etc.

      0                   1                   2                   3

Hi, Dave.

   Ron

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Wed, 13 Jul 2016 17:22:22 +0000

Reinaldo,
Yes, we suggest padding to 4-byte boundaries. But the length field should be in units of octets so that the real end of the octets is known.

-Dave

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 1:19 PM
To: Ron Parker; Dave Dolson; [email-masked]
Subject: Re: [sfc] A problem with NSH TLV

Hi, Dave.

   Ron

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 13 Jul 2016 19:08:24 +0000

As long as the length is in octet the padding can make cache friendly.

There is an open question on how to interpret a binary series of bytes, basically what is the encoding.  Just to make sure I am not PROPOSING that we add that too here. As long as there is default or explicit understanding we should be good. Opening up encoding discussion is a rathole, actually a sink hole that we don’t need.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 13, 2016 at 10:22 AM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] A problem with NSH TLV

Reinaldo,

-Dave

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Wednesday, July 13, 2016 1:19 PM
To: Ron Parker; Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] A problem with NSH TLV

Hi, Dave.

   Ron

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Wed, 13 Jul 2016 19:18:01 +0000

Each TLV type will have to explain the encoding--what is in the octets. I'm just making sure the length can work for TLVs that aren't exact multiples of 4 in length.

So will the editors of -nsh agree to make the change?

From: Sumandra Majee
Sent: Wednesday, July 13, 2016 3:08 PM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; [email-masked]
Subject: Re: [sfc] A problem with NSH TLV

Reinaldo,

-Dave

Hi, Dave.

   Ron

---------

----------

   OctetString

---------

----------

--------

-------

-Dave

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson