Subject: Updated text regarding Mutability in the SRH Draft

From: Bob Hinden <[email-masked]>
Date: Tue, 28 May 2019 14:54:50 -0700

Hello

Ole and I spent some time reviewing the email on the list and current text in <draft-ietf-6man-segment-routing-header-19.txt>.  We would like to propose the following text in Section 2.

- - - - -

OLD:

In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are
defined in Section 4.4 of [RFC8200] as not mutable.  The Segments
Left field is defined as mutable in Section 4.4 of [RFC8200].

Some of the other fields of the SRH change en route (i.e. they are
mutable).  The SRH is processed as defined in Section 4.3 of this
document, and uniquely per SID type.  The mutability of the remaining
fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are
defined in that section, in the context of segment processing.

NEW:

In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are defined in Section 4.4 of [RFC8200] as not mutable.  The Segments Left field is defined as mutable in Section 4.4 of [RFC8200].

The mutability of the TLV value is defined by the most significant bit in the type, as specified in section 2.1.

Section 4.3 defines the mutability of the remaining fields in the SRH (Flags, Tag, Segment List) in the context of the SID type defined in this document.

New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List.  Note, that in effect these fields are mutable.

- - - - -

We think this should resolve the open issues regarding defining mutability in SRH.  Please let us know what you think.

Thanks,
Bob & Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 16:14:48 -0700

> New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List.  Note, that in effect these fields are mutable.

Bob,

The idea that mutability requirements are dependent on SID (or SID
type) seems problematic. Joel already highlighted some of the
problems, for instance if a packet has three different SIDs with three
different sets mutability requirements, which requirements are
applicable for purposes like security and verification of the packet?
Note that this proposed text would implicitly break the HMAC TLV which
uses assumes these fields are immutable, i.e.:

"o  Text: a concatenation of the following fields from the IPv6 header
and the SRH, as it would be received at the node verifying the HMAC:
          *  IPv6 header: source address (16 octets)
          *  SRH: Last Entry (1 octet)
          *  SRH: Flags (1 octet)
          *  SRH: HMAC Key-id (4 octets)
          *  SRH: all addresses in the Segment List (variable octets)"

But, beyond the protocols implications, what I'm fundamentally missing
here is _why_ does mutability requirements need to depend on the SID.
Maybe the SRH authors have some specific use case or rationale in
mind, but this is not all obvious to the reader.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 May 2019 21:01:19 -0400

Between the rewording for clarity, and the note at the end making clear 
that this effectively makes all those SRH fields mutable, the text i 
snow clear.

While such mutability is not my preference, I can live with it and we 
need to get this done.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 18:35:15 -0700

> While such mutability is not my preference, I can live with it and we
Joel,

If this is the direction the working group chooses, then I suggest
that an SRH 'M' flag be defined to indicate whether or not the SID
list is mutable. So for instance, if a mutable SID is inserted in the
list then the flag would be set, if the list is just IPv6 SIDs then
the flag isn't set. Entities, like AH and HMAC TLV, would then be able
to use this flag to unambiguously determine whether the SID list is
mutable in a packet (e.g. whether to include the SID list in input
text for verification). This also preserves the ability of the host to
control what is mutable in the packet it sources, and allows it to
verify through AH or HMAC TLV that the packet wasn't improperly
modified in flight. This implies the flags are not mutable. I don't
think tags field really matter much for mutability as long as its
clear up front whether it is a mutable field or not.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 30 May 2019 17:05:04 +0000

Thanks Bob and Ole for the text, I think this accurately summarizes the current state of the specification.
It’s been a couple days so I’ll plan to make this edit to rev20.

Darren

> On May 28, 2019, at 9:01 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Between the rewording for clarity, and the note at the end making clear that this effectively makes all those SRH fields mutable, the text i snow clear.
> 
> While such mutability is not my preference, I can live with it and we need to get this done.
> 
> Yours,
> Joel
>