Subject: Re: Updated text regarding Mutability in the SRH Draft

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 4 Jun 2019 17:47:20 +0000

Hi Tom, I expect we would add the M flag to an AH draft.

Flags would remain mutable as per the text proposed, though you can say in the definition of an M bit that it is not mutable at intermediate nodes.

Darren

On May 28, 2019, at 9:35 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 28, 2019 at 6:01 PM Joel M. Halpern <[email-masked]<mailto:[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.

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

Yours,
Joel

On 5/28/19 5:54 PM, Bob Hinden wrote:
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

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

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

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Jun 2019 11:06:58 -0700

> Flags would remain mutable as per the text proposed, though you can say in the definition of an M bit that it is not mutable at intermediate nodes.

Darren,

The HMAC computation includes the flags, last entry, and the addresses
in the segment list as text input. So between the source setting the
HMAC TLV and the node that verifies the HMAC, which per the draft
could be any node in the path, these fields must not change or the
HMAC verification fails. In fact, one of the stated goals of the HMAC
in the draft is to "ensure the segment list is not modified in
transit". So if these fields are mutable then I don't see how HMAC can
properly work.

Tom

>
> Darren
>
> On May 28, 2019, at 9:35 PM, Tom Herbert <[email-masked]> wrote:
>
> On Tue, May 28, 2019 at 6:01 PM Joel M. Halpern <[email-masked]> wrote:
>
>
> [email-masked]
> [email-masked]
> [email-masked]

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 4 Jun 2019 18:34:25 +0000

"The HMAC TLV is used to verify the source of a packet is permitted to
   use the current segment in the destination address of the packet, and
   ensure the segment list is not modified in transit.”

Should someone want an HMAC TLV that does something else, they are free to define one.

Darren

> On Jun 4, 2019, at 2:06 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Jun 2019 11:59:44 -0700

Darren,

I am trying to understand how HMAC TLV and the mutability requirements
defined in the latest work in unison. The HMAC TLV clearly implies
that the flags, last entry, and segment list are immutable; and the
recent mutability requirements state that flags and segment list may
be mutable at least under certain conditions. How do you reconcile
this two seemingly conflicting requirements? Perhaps the intent is
that the node setting HMAC would be somehow know that the SRH is
mutable and so not set the HMAC to avoid the verification failure
problem-- or maybe there is some other implied mechanism to ensure
robustness. In any case, it's unclear in the current draft.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 4 Jun 2019 19:23:52 +0000

Hi Tom, the document describes a scenario where an SRH and HMAC is provided to an SR Source node and some subsequent node verifies what the SR Source added via HMAC verification.
This is clear in the document.

If there are other scenarios for other SIDs defined in the future I would expect some future document to define how that works if and when it’s needed.

Darren

> On Jun 4, 2019, at 2:59 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Jun 2019 12:38:47 -0700

> If there are other scenarios for other SIDs defined in the future I would expect some future document to define how that works if and when it’s needed.
Then the draft should state that. HMAC TLV can only be used with the
SIDs defined in this document.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 4 Jun 2019 20:18:24 +0000

The draft does state how the HMAC TLV is verified and used.
There is a TLV registry for other TLVs to be defined.
Should other scenarios or TLVs be required, subsequent documents can define them.

Darren

> On Jun 4, 2019, at 3:38 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Jun 2019 16:14:27 -0700

Darren,

I don't see where in the draft the usage scenario for HMAC is defined. It's
only an inference that there are scenarios where HMAC doesn't work when the
input fields are mutable. Not all readers or implentors will catch this
subtlety and it should be clarified IMO.

Tom

> >> Hi Tom, the document describes a scenario where an SRH and HMAC is
> provided to an SR Source node and some subsequent node verifies what the SR
> Source added via HMAC verification.
> >> If there are other scenarios for other SIDs defined in the future I
> would expect some future document to define how that works if and when it’s
> needed.
> >>
> >>>>>> Flags would remain mutable as per the text proposed, though you can
> say in the definition of an M bit that it is not mutable at intermediate
> nodes.
> >>>>>
> >>>>> Darren,
> >>>>>
> >>>>>> 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].
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>