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

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

By the way, I assume you do not actually mean "sender" by source.  The 
use cases you describe often have the knowledge at the controller, not 
the sender.  So the source is the source of the SRH, but not the soure 
of the packet.
Yours,
Joel

On 6/5/19 1:01 PM, Darren Dukes (ddukes) wrote:
> Joel the answer is simple and the same as usual.  The SR Source ALWAYS knows how to steer a packet in the SR Domain.
> 
> The SR Source (or a path compute node) would never add segments to a segment list in an order it knows cannot work.
> 
> Darren
> 
> 
>> On Jun 5, 2019, at 12:48 PM, Joel M. Halpern <[e-mail]> wrote:
>>
>> Your response on the HMAC validation implies that someone on the far side of a SDI that modifies the SID list (e.g. a binding SID) would somehow know not to try to validate the HMAC?  Or would the Binding SID process be requried to remove the HAMC TLV?  Or?
>>
>> Treating this as something can be deferred until a future SID is defined that changes SID lists is at best disingenuous.  These behaviors have implications for devices which try to support what is here, even if they are not upgraded to support new functionality.  For example, in the above, a device on the far side of a binding SID does not itself need to know anything about binding SIDs.  But it apparently needs to know something to decide whether it can verify the HMAC>  And no, local policy is not a good enough hook since this obviously depends upon the particular SID sequence the packet has gone through, not on the role of the device.
>>
>> Yours,
>> Joel
>>
>> On 6/5/19 12:41 PM, Darren Dukes (ddukes) wrote:
>>> Hi Joel, there is no definition of a "binding SID" that modifies a Segment list.
>>> However it is obvious if I intend to modify a segment list within an SR Domain, AND I want to verify that segment list via an HMAC TLV, I would certainly do the verification before my modification.
>>> Darren
>>>> On Jun 5, 2019, at 11:13 AM, Joel M. Halpern <[e-mail]> wrote:
>>>>
>>>> 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
>>>>> --------------------------------------------------------------------
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>