Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

["Joel M. Halpern" <[e-mail]>]

Apparently I am just dense.
If we intend to permit the SID list to change along the way (for example 
with binding SIDs) then how does the HMAC TLV work?  The TLV is supposed 
to be verifiable along the path.  But the SID list is different before 
and after the binding SID.  So the same HMAC can not protect the two SID 
lists.

Do we want to restrict the HMAC TLV to be only processed by the first 
router on the path?  Do we want to declare that the HMAC can not be used 
with any behavior that modifies the SID list?

I guess I can take the view that folks are never going to implement the 
HMAC, as it is so loosely specified.  But if I expect it to work, we 
need some clarity on behavior.

And that is putting aside the question of whether one wants to see AH 
usable with SRH.  With the mutability as currently specified, AH will 
have to ignore the SRH.  Which is okay if we and the security community 
agree.

Yours,
Joel

On 6/5/19 11:05 AM, Tom Herbert wrote:
> On Wed, Jun 5, 2019 at 1:21 AM Chengli (Cheng Li) <[e-mail]> wrote:
>>
>> Hi Darren,
>>
>>
>>
>> Thanks for your reply. It seems like reasonable to pre-allocate space for IOAM. Also, PBT[1] based Telemetry can avoid this problem.
>>
>>
>>
>> However, in Stateless SFC[2], the NSH TLV can be included in SRH to carry metadata. The length of metadata may be mutable and hard to be pre-computed when the MD type is 2.
>>
>> Maybe we still can pre-allocate enough space for this scenarios, but I still think we should make HDR as mutable.
>>
>>
>>
>> The fields that will not be changed en route will not affect the length of the SRH.
>>
>> The mutable fields  will not count when compute ICV, and the changes of them are allowed, so why to limit  the change of length? There is no need to limit the length of these fields, because this does not help on Authentication but brings limitation.
>>
>>
>>
>> It is a general problem for IOAM and SFC, which need to add metadata into data packets.
>>
> Hi Chengli,
> 
> Please look at https://trac.ietf.org/trac/6man/ticket/69 which
> describes some of the operational problems of adding/deleting TLVs.
> There is also an attribution problem.
> 
> The contents of a packet are attributed to the source which is
> indicated by the source address. Fundamentally, the source of the
> packet owns the bits and is responsible for the content. If an
> intermediate node sets alternative content in a packet then at the
> destination that content is attributed to the source. This content may
> not conform to host policy, or for that matter might even be illegal,
> and without any proper paper trail of who set the content, the source
> is held accountable.
> 
> So the source requires fine grained control over what the network is
> allowed to change, and authentication is means to enforce that
> intermediate nodes only change the packet in permissible ways. If a
> network node wants to change more than what the source allows, it is
> free to encapsulate the packet for transit across the network, thus
> itself becoming the source of the packet and so can set content in the
> encapsulating headers per a different policy.
> 
> Tom
> 
>>
>>
>> Thanks,
>>
>> Cheng
>>
>>
>>
>>
>>
>> [1] https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-03
>>
>> [2] https://tools.ietf.org/html/draft-xuclad-spring-sr-service-programming-02#section-7.2.1
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: Darren Dukes (ddukes) [mailto:[e-mail]]
>>
>> Sent: Tuesday, May 28, 2019 1:22 AM
>>
>> To: Chengli (Cheng Li) <[e-mail]>
>>
>> Cc: Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
>>
>> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>>
>>
>>
>> Hi Cheng, thanks for the support, I have a couple comments inline.
>>
>>
>>
>>
>>
>>> On May 27, 2019, at 8:41 AM, Chengli (Cheng Li) <[e-mail]> wrote:
>>
>>>
>>
>>> Support. Many thanks to authors for their contributions! I agree that we should specify how the AH works with SRH in other drafts.
>>
>>>
>>
>>> But I can NOT find any text of describing Hdr Ext Len is not mutable in RFC8200.
>>
>>> Hdr Ext Len SHOULD be mutable, otherwise, use cases like incremental SRv6 IOAM[1] can not work.
>>
>>
>>
>> draft-ali-6man-spring-srv6-oam-01 actually reserves TLV at an SR Source node for use by segment endpoint nodes, so it doesn’t change the size of TLVs (see 4.4.2.1 and 4.4.2.2 of that draft).
>>
>>
>>
>>> All the use cases of inserting or deleting new TLV, or updating TLV with new length value are not allowed if Hdr Ext Len is not mutable.
>>
>>
>>
>> Use cases you’re thinking of should be able to use a method similar to that in draft-ali-6man-spring-srv6-oam, I would be interested to hear about them.
>>
>>
>>
>> Thanks
>>
>>    Darren
>>
>>
>>
>>>
>>
>>> I think it is a limitation to SRv6 that we should avoid it definitely.
>>
>>>
>>
>>>
>>
>>> Best Regards,
>>
>>> Cheng
>>
>>>
>>
>>> [1]. https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01#section-4.4.1
>>
>>>
>>
>>> -----Original Message-----
>>
>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Bob Hinden
>>
>>> Sent: Wednesday, May 22, 2019 9:40 PM
>>
>>> To: IPv6 List <[e-mail]>
>>
>>> Cc: Bob Hinden <[e-mail]>
>>
>>> Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>>
>>>
>>
>>> Hello,
>>
>>>
>>
>>> This message starts a new two week 6MAN Working Group Last Call on advancing:
>>
>>>
>>
>>>        Title           : IPv6 Segment Routing Header (SRH)
>>
>>>        Authors         : Clarence Filsfils
>>
>>>                          Darren Dukes
>>
>>>                          Stefano Previdi
>>
>>>                          John Leddy
>>
>>>                          Satoru Matsushima
>>
>>>                          Daniel Voyer
>>
>>>              Filename        : draft-ietf-6man-segment-routing-header-19.txt
>>
>>>              Pages           : 32
>>
>>>              Date            : 2019-05-21
>>
>>>
>>
>>>     https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
>>
>>>
>>
>>> as a Proposed Standard.
>>
>>>
>>
>>> This document was in an extended last call that started in March of 2018.   An issue tracker was set up, and eight new versions of the draft were produced and discussed on the list and at face to face 6man sessions.   All of the issues in the tracker have been closed.  The chairs believe it is ready to advance, but given the number of changes and the time that elapsed, a new w.g. last call is warranted.  Please review the new document.
>>
>>>
>>
>>> Our thanks to the authors/editors and the working group for the work on this document.
>>
>>>
>>
>>> Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author.  This last call will end on 5 June 2019.
>>
>>>
>>
>>> Thanks,
>>
>>> Bob & Ole
>>
>>>
>>
>>>
>>
>>>
>>
>>>
>>
>>> --------------------------------------------------------------------
>>
>>> IETF IPv6 working group mailing list
>>
>>> [e-mail]
>>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>>> --------------------------------------------------------------------
>>
>>>
>>
>>> --------------------------------------------------------------------
>>
>>> IETF IPv6 working group mailing list
>>
>>> [e-mail]
>>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>>> --------------------------------------------------------------------
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>