Subject: TLVs and segment routing

From: Tom Herbert <[email-masked]>
Date: Wed, 23 May 2018 14:58:18 -0700

Hello,

Looking at latest SR draft
(draft-ietf-6man-segment-routing-header-13), I still have concerns
with TLVs here.

My biggest issue is that "Unrecognized Types MUST be ignored on
receipt". This implies the simple DOS attack where an attacker fills
an SR EH with tiny TLVs having types that will be unknown to
receivers. For SR it looks like the minimum TLV size is 2 bytes, so
there could easily be a hundred of these in a single SR EH-- that
would be a burden for SW or HW to handle! DO and HBH options have
similar attack vectors, for that we want to allow implementations to
enforce limits on how much they are willing to process
(draft-ietf-6man-rfc6434-bis-08).

AFAICT there is only one real TLV being defined so far (HMAC TLV in
the draft). The odd thing about this is that when the HMAC TLV is
present then the H bit in the flags must also be set. This is
redundant information about the presence of the option and introduces
potential error conditions that must be considered (like what if H bit
is set but the HMAC TLV is not present, or TLV is present but H bit is
not set...).

Furthermore, if the H bit must be set, then why not just use that as
the indication that the HMAC data is present and dispense with the
need to have it in a TLV. For instance, the rule could be that if the
H bit is set then the thirty two octets following the last segment
could be the HMAC. In this way the flags becomes flag-fields like in
GRE or GUE and could be extrapolated for use with other potential
options. This technique might even eliminate the need for TLVs in SR
entirely. IMO, not introducing new TLVs in a primary L3 data path
protocol is a good thing!

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 25 May 2018 18:46:11 +0000

Hi Tom, see inline.
I see three main concerns:
1 - TLV should be limited as per draft-ietf-6man-rfc6434-bis-08.
  - ACK, perhaps we should be bringing text from  draft-ietf-6man-rfc6434-bis-08 section 5.3 into this document.
2 - Only one TLV defined:
  - Service Function Chaining will define and make use of another TLV
  - Other documents will define other TLVs and their use.
3 - H bit:
  - I’m thinking on this for a bit.

Darren

> On May 23, 2018, at 5:58 PM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 May 2018 15:46:10 -0400

The service function chaining working group might disagree with the 
general statement that service function chaining will define and make 
use of SRv6 TLVs.

The argument for the MPLS service chaining work diverging from the NSH 
work the IETF has approved was based on MPLS being a standardized and 
widely deployed mechanism that can be used as a transition mechanism to 
NSH.  I don't see how SRv6 can make that argument.

If we as a community want to see how many incompatible service chaining 
solutions we can define, we can do that.  I do not expect our customers 
to thank us for doing so.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Sun, 27 May 2018 11:14:42 -0700

On Fri, May 25, 2018, 11:46 AM Darren Dukes (ddukes) <[email-masked]>
wrote:

>   - ACK, perhaps we should be bringing text from
> draft-ietf-6man-rfc6434-bis-08 section 5.3 into this document.

Hi Darren,

This seems to be falling into the same line of thinking that so many others
have taken wrt TLVs. The facility is added to network layer protocols for
the sake of making the protocol "extensible". But in practice, very few
useful TLVs are ever defined in these cases (consider HBH or DO options in
IPv6), or even no useful ones are ever defined (like IPv4 options). To make
matters worse, if TLVs aren't necessary and common (unlike TCP options),
then we've seen many times that implementations will either relegate TLV
processing to a slow path or just drop packets instead of processing them.
In either case, this makes it really hard to deploy when someone does
define a useful TLV. And then if TLVs are allowed, there needs be
significant thought into DOS as already mentioned. This is why I think it's
better not to introduce a new TLV mechanism unless absolutely needed. I
don't yet see that they're needed in SR.

Tom