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

[Joel Halpern Direct <[e-mail]>]

My problem is not how the segment list gets into the SRH.  I agree that 
has been settled.

My concern is the interaction between the argument that the segment list 
is mutable and the HMAC validation.  If the segment list is mutable, 
then either the HMAC is valid when the packet is sent, and invalid when 
teh segment list changes, or the HMAC is invalid when the segment list 
is sent, and valid when it changes.  But nothing in the packet tells a 
potential validator that the HMAC does or does not currently apply to 
the packet.

You can get around this in multiple ways.
We can drop the HMAC.
We can declare that any entity that modifies the segment list MUST 
remove the HMAC  (and, if you like, may put a new HMAC on).
We can, as Tom suggested, have a bit that says whether this packet is 
using a mutable segment list; and if so the segment list is not covered 
by the HMAC.
What I think is unacceptable is to say that the SRH creator will 
magically know where the validators are and what they will validate, and 
will manage to create the right HMAC for all cases.

You have declared that segment list modifiability is dependent upon SID 
type.  But the generation and validation of the HMAC can occur at points 
where the SID is not specifying modifiability even if other SIDs in the 
list do specify modifiability.

Yours,
Joel

On 6/5/19 5:08 PM, Darren Dukes (ddukes) wrote:
> Joel, let's reset.
> 
> We were discussing HMAC validation by a segment within a segment list within an SR Domain as it pertains to draft-ietf-6man-segment-routing-header
> It is clear that the HMAC TLV can do what it says - verify the segment list set by the SR Source (AKA Source SR node).
> The Source SR node is defined in (section 5.1).
> Section 5.1 also states:
>     The mechanism through which a segment in the destination address of
>     the IPv6 header and the Segment List in the SRH, is derived is
>     outside the scope of this document.
> 
> This text has been present in the document since December 2015!
> 
> Further debate, in the context of this working group last call for draft-ietf-6man-segment-routing-header, of how the SRH and segment list is computed, the intent behind that computation, and what many things it may or may not need to consider to compute a segment list is clearly out of scope.
> 
> Thanks
>    Darren
> 
>> On Jun 5, 2019, at 2:16 PM, Joel M. Halpern <[e-mail]> wrote:
>>
>> Not sure I follow.
>> Your statement is that the "SR Source ALWAYS knows how to steer a packet...".
>> In the (not uncommon) case where a PCE provides the SRH, it seems quite likely that the node sending the packet will not have any idea what the SID types in the list are, or wht subtle interactions there may be either within the SRH or between the SRH and other extensions (such as AH) that the sending node may want to use.
>>
>> You say below that one can use "SR Source" to mean both the packet sender and the path computation entity.  But when they are different nodes, they have different knowledge.  So I do not see how it suffices to say that you mean the combination of the two.
>>
>> Remember that our goal is interoperability of independent implementations, which includes the case wher ethe packet sender (either intra-domain source or domain edge node) is not only distinct from the PCE, but may well be from different vendors.  That's the point of the spec.
>>
>> I note also that if we can truly consider the PCE and the packet sender to always be the same, then the use case in the document for the HMAC does not apply, since they are then presuambly equally trusted.
>>
>> Yours,
>> Joel
>>
>> On 6/5/19 2:10 PM, Darren Dukes (ddukes) wrote:
>>> SR Source node means sender.
>>> In the text below I said SR Source (or a path compute node).
>>> You may use SR Source to mean the sender and the path compute node, because the physical location of the process that computes a path from SR Source to a destination is not relevant to this discussion.
>>> Darren
>>>> On Jun 5, 2019, at 2:05 PM, Joel M. Halpern <[e-mail]> wrote:
>>>>
>>>> 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
>>>>>>>> --------------------------------------------------------------------
>