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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 3 Jun 2019 19:46:55 +0000

Hi Med, this was closed by the WG during the previous last call, concluding with this text.

Darren

> On May 27, 2019, at 5:02 AM, [email-masked] wrote:
> 
> Hi Bob, all,
> 
> I do still don't understand the intent of this field:  
> 
>   o  Tag: tag a packet as part of a class or group of packets, e.g.,
>      packets sharing the same set of properties.  When tag is not used
>      at source it MUST be set to zero on transmission.  When tag is not
>      used during SRH Processing it SHOULD be ignored.  Tag is not used
>      when processing the SID defined in Section 4.3.1.  It may be used
>      when processing other SID types which are not defined in this
>      document.  The allocation and use of tag is outside the scope of
>      this document.
> 
> In the absence of a clear definition of this field, it is better to set these bits as unassigned. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : ipv6 [mailto:[email-masked]] De la part de Bob Hinden
>> Envoyé : mercredi 22 mai 2019 15:40
>> À : IPv6 List
>> Cc : Bob Hinden
>> Objet : 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
>> [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
> --------------------------------------------------------------------

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 5 Jun 2019 07:03:51 +0000

Hi Tom,

Please see inline.

Cheng

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, May 27, 2019 11:41 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

On Mon, May 27, 2019 at 5:42 AM Chengli (Cheng Li) <[email-masked]> 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.

Chengli,

Extension headers are not inserted or deleted by any node along a packet's delivery path per RFC8200. Changing the length of an extension header is equivalent to deleting an extension header and inserting a new one in its place.

[Cheng] Then we should updated the RFC8200? Otherwise, TI-LFA, Binding SID and Insertion mode can not work. But this is not related to SRH drafts. We need another draft maybe to describe that if needed.

> Hdr Ext Len SHOULD be mutable, otherwise, use cases like incremental SRv6 IOAM[1] can not work.

This topic has come up before in 6man list, in fact this is the subject of draft-voyer-6man-extension-header-insertion-05. In those discussions, issues in robustness, accountability and attribution (both for operational and legal purposes), security, operations (breaks ICMP for instance) have been brought up. The proponents of extension header insertion have yet to adequately address those issues.

> 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.

Adding and deleting TLVs is the topic in "https://trac.ietf.org/trac/6man/ticket/69", please look at that. Note that the ticket is closed, but it's pretty obvious that this it is not resolved and the text in the latest draft seemingly creates a loophole to do this by defining a "SID type" for that purpose.

>
> I think it is a limitation to SRv6 that we should avoid it definitely.

Then it's also a general limitation in IPv6. For instance, IOAM is useful networks that don't use segment routing. So if Adding/Deleting TLVs is needed for SR TLVs then there's also needed for Hop-by-Hop options. But, rather this is necessary and sufficient has yet to be proven. There are two alternatives to adding TLVs: 1) Use IP encapsulation which properly allows "EH insertion" in the outer header since the encapsulator is sourcing an IPv6 packet 2) Use a mutable TLV type (defined for HBH, DO, and SR options) that includes sufficient scratch space for intermediate nodes to write their data.

[Cheng] Regarding IOAM, I can not see how incremental  IOAM can work if adding TLV is forbidden. Luckily, we can use PBT based Telemetry to avoid this limitation:  https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-03

Tom

>
>
> 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:[email-masked]] On Behalf Of Bob Hinden
> Sent: Wednesday, May 22, 2019 9:40 PM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> 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:
>
> 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
>
>
>
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 5 Jun 2019 08:20:54 +0000

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.

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

Sent: Tuesday, May 28, 2019 1:22 AM

Hi Cheng, thanks for the support, I have a couple comments inline.

> On May 27, 2019, at 8:41 AM, Chengli (Cheng Li) <[email-masked]> wrote:

> 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

> [1]. https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01#section-4.4.1

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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Jun 2019 08:05:03 -0700

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 11:13:43 -0400

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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Jun 2019 08:19:55 -0700

> have to ignore the SRH.  Which is okay if we and the security community
Or, just have a bit somewhere that indicates that the SID list is
mutable. Both HMAC and AH can consume the bit to determine whether to
include SID list as input text.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 5 Jun 2019 16:41:51 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 12:48:53 -0400

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 5 Jun 2019 17:01:37 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 13:05:56 -0400

Hmmm.  In most IETF protocols we include text along the lines of "do not 
send X, as the receiver will not be able to process it".  We do so 
because calling that out helps people build compliant implementations.
Your comment below seems to say "yes, we know lots of combinations won't 
work, but we won't tell you which ones.  Implementors have to figure 
that out for themselves."

Doesn't seem like a good practice for high quality specifications.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Jun 2019 10:31:14 -0700

> Joel the answer is simple and the same as usual.  The SR Source ALWAYS knows how to steer a packet in the SR Domain.

Darren,

If the source knows everything, then why does the segment list need to
be mutable in the network?

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 14:05:04 -0400

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 5 Jun 2019 18:10:58 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 14:16:46 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Jun 2019 08:47:57 +1200

Hi Cheng,
> [Cheng] Then we should updated the RFC8200? Otherwise, TI-LFA, Binding SID and Insertion mode can not work. But this is not related to SRH drafts. We need another draft maybe to describe that if ne…

No, this was debated at length during the development of RFC8200 and was clearly
excluded. I will not repeat the arguments here, but it is all in the list archive.

> This topic has come up before in 6man list, in fact this is the subject of draft-voyer-6man-extension-header-insertion-05. In those discussions, issues in robustness, accountability and attribution…

Exactly. (And this is one of the motivations for draft-carpenter-limited-domains. There might be scenarios where we could deviate from the current rules, but they are not scenarios involving the open Internet.)

>> 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.

Exactly. And it isn't mutable. Hence the need for the encapsulation model for SRH or IOAM in general. None of this discussion is new.

   Brian

> .

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 5 Jun 2019 21:08:22 +0000

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

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 5 Jun 2019 17:43:51 -0400

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

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 6 Jun 2019 02:46:42 +0000

Great!  https://trac.ietf.org/trac/6man/ticket/69 is really helpful!  

Thanks for your reply. I agree that the Hdr Ext Len is reasonable to be immutable.

Regards,
Cheng

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2019 11:05 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

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-0
> 3
>
> [2] 
> https://tools.ietf.org/html/draft-xuclad-spring-sr-service-programming
> -02#section-7.2.1
>
>
>
>
>
> Subject: Re: 6man w.g. last call for 
> > https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01#sectio
> > n-4.4.1
>
> >
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 6 Jun 2019 03:07:06 +0000

Hi Brian,

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, June 06, 2019 4:48 AM
To: Chengli (Cheng Li) <[email-masked]>; Tom Herbert <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

Hi Cheng,
> [Cheng] Then we should updated the RFC8200? Otherwise, TI-LFA, Binding SID and Insertion mode can not work. But this is not related to SRH drafts. We need another draft maybe to describe that if ne…

No, this was debated at length during the development of RFC8200 and was clearly excluded. I will not repeat the arguments here, but it is all in the list archive.

Exactly. And it isn't mutable. Hence the need for the encapsulation model for SRH or IOAM in general. None of this discussion is new.
[Cheng] Agree with the Hdr Ext Len is immutable, and the encapsulation model is needed. Many thanks!

   Brian

> [Cheng] Regarding IOAM, I can not see how incremental  IOAM can work 
> if adding TLV is forbidden. Luckily, we can use PBT based Telemetry to 
> avoid this limitation:

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 6 Jun 2019 03:50:32 +0000

Hi Joel,

As my understanding, the HMAC TLV is used only for verifying the packets from the hosts WITHIN the SRv6 domain. 
And the HMAC TLV will be verified only once at the ingress router.
After the ingress router, we assume that the network is trusted and there is no need to verify again.
Like the example described at https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-19#section-6.6.1

So the HMAC TLV is used for making sure that the packets are not changed between the hosts(within the SRv6 domain) and the ingress router. 
Based on that, I think local policy on the external interface(facing to hosts)  works for HMAC processing. 

After this sub-path, the SID list can be changed, and the HMAC is ignored when processing. Although I don't see scenarios to change the SID list, except https://tools.ietf.org/html/draft-li-spring-light-weight-srv6-ioam-00

I don't agree to add or delete HMAC TlV along the path, this equals to add a new SRH.  Ignoring HMAC TLV on internal interface is a good choice.

Best Regards,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Thursday, June 06, 2019 5:44 AM
To: Darren Dukes (ddukes) <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

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
>>>>>>>>> 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-te
>>>>>>>>>> lemetry-03
>>>>>>>>>>
>>>>>>>>>> [2] 
>>>>>>>>>> https://tools.ietf.org/html/draft-xuclad-spring-sr-service-pr
>>>>>>>>>> ogramming-02#section-7.2.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-0
>>>>>>>>>>> 1#section-4.4.1
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Administrative Requests: 
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> ------ 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

---

From: <[email-masked]>
Date: Thu, 6 Jun 2019 07:21:18 +0000

Hi Darren, 

I may missed where this was discussed, but this text is underspecified/not clear. 

The text says explicitly that the use of this tag is out of scope. It is weird to provision a field for something we don't know/understand (from the reading of the spec).

Cheers,
Med

> De : Darren Dukes (ddukes) [mailto:[email-masked]]
> Envoyé : lundi 3 juin 2019 21:47
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Bob Hinden; IPv6 List
> Objet : Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-
> header-19.txt>
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 6 Jun 2019 08:56:27 -0400

Your assumption that the HMAC will only be verified at the ingresss 
router would change the question.  While that is the use case described 
in the document, it is not the behavior document as the definition or 
requirement.  It is documented to be verifiable along the path, not just 
at the first router.

Yours,
Joel

On 6/5/19 11:50 PM, Chengli (Cheng Li) wrote:
>>>>>>>>>>> -------
>>>>>>>>>> ------
>>>>>>>>> -----

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 6 Jun 2019 13:28:23 +0000

Hi Joel, as you’ve agreed, the SR Source node determines what segments are placed in the SRH through a means outside the scope of this document.

RFC8402 abstract - "A node steers a packet through an ordered list of instructions, called "segments”.”

The SR Source obviously knows what each segment does in order to build the segment list.
Read the multiple drafts for SRv6 and ISIS, OSPF, BGP-LS, network-programming to understand how it knows what segments do.

The SR Source relies on that knowledge to add any TLV to the SRH containing it's computed segment list, otherwise it would never know why or what to add.

HMAC is no different.  It must know that segments in its segment list will validate the HMAC and what key id to use so they can do so.

Therefor it is entirely acceptable and necessary for the SRH creator to know where the validators are and what they will validate so it knows how to build the segment list and HMAC TLV.

Darren

> On Jun 5, 2019, at 5:43 PM, Joel Halpern Direct <[email-masked]> wrote:
>

---

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 6 Jun 2019 13:44:19 +0000

Hi,

Also support publication of this draft.

thanks 

Dan B
________________________________________
From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Sent: Wednesday, May 22, 2019 9:39 AM
To: IPv6 List
Cc: Bob Hinden
Subject: [EXT]6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

Hello,

as a Proposed Standard.

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
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Tom Herbert <[email-masked]>
Date: Thu, 6 Jun 2019 07:58:20 -0700

> will manage to create the right HMAC for all cases.
Joel,

Agreed. I would point out that mutability bit approach is simple and
straightforward. For the cost of one bit this "magic" (i.e. a
perfectly orchestrated control plane) is not necessary for correct
operation of HMAC. This brings consistency with other extension
headers where the mutability of fields is either specified in the
protocol or the fields are self-identifying to be mutable. It also
simplifies the "SID list can be mutable" concept that was introduced
in the latest draft; all the dataplane (e.g. for HMAC and AH) needs to
know is whether the SID list is mutable, we don't care why it's
mutable or that it's mutable because it contains SID types that make
it mutable. So all the draft really needs say concerning SID list
mutability is "if the M bit is set then the SID list is mutable,
otherwise it is immutable".

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 8 Jun 2019 10:38:52 -0400

All

I support the draft.

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

> On Jun 6, 2019, at 9:44 AM, Bernier, Daniel <[email-masked]> wrote:
> 
> Hi,
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 14 Jun 2019 10:55:15 -0700

The 6man chairs believe there is a consensus to advance draft-ietf-6man-segment-routing-header-21.txt to the IESG to be published as a Proposed Standard.

It’s been a long road to get here.  Two working group last calls, many presentations at 6man IETF sessions, and countless emails on the list.   We think that the current document (-21) is significantly improved based on discussion on the list and resolves the issues raised.   The changes since -19 include:

draft-ietf-6man-segment-routing-header-20

 - Updates the mutability text in section 2 as discussed on the list.
 - Changed pad0 to pad1
 - Updates the TLV type registry definition for IANA (pending verification)
 - Changed “SID Type” to “SID”.
 - Changed TLV mutability text to align with RFC8200.

 https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-20.txt

draft-ietf-6man-segment-routing-header-21

 - Added request to IANA considerations section for ICMP “SR Upper-layer
   Header Error and a request for ICMPv6 Parameter Problem error
   code assignment.
 - Removed reservations of TLV types 3 and 6 for opaque and NSH TLVs based
   on draft-xuclad-spring-sr-service-programming.  That draft requires new
   allocations in the mutable range for TLV types, the authors realized
   the current values won’t be usable any longer.
 - Changed TLV type in IANA Considerations for Type 3 and 6 to Reserved

 https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-21

We think the 6MAN consensus is strong to advance, but clearly not unanimous.  

We plan to submit the shepherd's writeup and advance the document in the next few days.  Like all  documents we request for advancement, it will undergo AD review, then an IETF Last call, IESG directorate reviews, and AD reviews, followed by an IESG teleconference ballot.   

We want to thank the 6man working for all of the feedback on this draft and the authors for resolving the issues.

Thanks,
Bob & Ole

> On May 22, 2019, at 6:39 AM, Bob Hinden <[email-masked]> wrote:
> 
> Hello,
>