Subject: Re: TLVs and segment routing

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 30 Jun 2018 14:01:23 +0000

Hi Tom, in revision 14 we looked at how to better define TLV processing and as such we removed the H flag and defined the TLV processing as based on local policy of the SR Segment Endpoint Node.

Please take a look at the text.

As for https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-08#section-5.3 did you have any thoughts?  I think the last two paragraphs in that section can be reused in the SRH draft. for example: a host may drop packets with unknown TLV types, may impose a limit on the length of the routing header processed, may impose a limit on number of TLVs.  All these should be configurable.

Darren

On May 25, 2018, at 2:46 PM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>> wrote:

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------