Subject: Re: TLVs and segment routing

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Jul 2018 11:55:41 -0700

On Sat, Jun 30, 2018 at 7:01 AM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 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.

Hi Darren,

Thanks, removing the H flag is an improvement.

>
> 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.
>
I suppose, but more generally though maybe these TLVs should have the
same format as Destination and HBH Options and share similar
properties including bits in type about unrecognized options and DOS
mitigation.

In any case, as I mentioned previously the case for including TLVs in
SR EH doesn't seem very strong, but making their processing optional
per "local policy" seems to really be telegraphing to vendors to not
bother implementing support for them in the fast datapath. i.e. from
draft:

       If local policy requires TLV processing {
         Perform TLV processing (see TLV Processing)
       }

Tom

> Darren
>
>
>
> On May 25, 2018, at 2:46 PM, Darren Dukes (ddukes) <[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]> 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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>