Subject: Issue #69 - Ron

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 28 Mar 2019 19:53:39 +0000

Hi Bob and Ole, as discussed here is the SRH mutability definition text with the SRH identified as mutable, with removal of the change bits in the TLVs (As AH will just mark the header as 0).

Hi Ron, since you opened this item, can you ack the closure please – this adds the mutability section to the security section.

<OLD>
5.4.  AH ICV

   Within the domain, an SR source node which includes SRH and AH
   extension headers can predict the content of the SRH and calculate
   the ICV at the SR source node, ensuring it can be confirmed at the
   destination.

5.5.  ESP ICV

   Within the domain, an SR source node may include SRH and ESP
   extension headers.  Only the data following the ESP header is
   included in ICV computation.  SRH precedes ESP.
</OLD>
<NEW>
</NEW>

<OLD>
</OLD>
<NEW>
7.5.  AH ICV computation
   For the purpose of AH ICV computation, the SRH is considered mutable.
</NEW>

<OLD>
8.2<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-16#section-8.2>.  Segment Routing Header TLVs Register

   This document requests the creation of a new IANA managed registry to
   identify SRH TLVs.  The registration procedure is "Expert Review" as
   defined in [RFC8126<https://tools.ietf.org/html/rfc8126>].  Suggested registry name is "Segment Routing
   Header TLVs".  A TLV is identified through an unsigned 8 bit
   codepoint value.  The following codepoints are defined in this
   document:

   Suggested      Description               Reference
     Value
   -----------------------------------------------------
      5           HMAC TLV                  This document
      128         Pad0 TLV                  This document
      129         PadN TLV                  This document
</OLD>
<NEW>
8.2<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-16#section-8.2>.  Segment Routing Header TLVs Register

   This document requests the creation of a new IANA managed registry to
   identify SRH TLVs.  The registration procedure is "Expert Review" as
   defined in [RFC8126<https://tools.ietf.org/html/rfc8126>].  Suggested registry name is "Segment Routing
   Header TLVs".  A TLV is identified through an unsigned 8 bit
   codepoint value, with assigned values 0-255.  The following codepoints are defined in this document:

   Suggested      Description               Reference
     Value
   -----------------------------------------------------
      0           Pad0 TLV                  This document
      1           PadN TLV                  This document
      5           HMAC TLV                  This document
</NEW>

Thanks.
  Darren

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Mar 2019 21:25:55 +0100

On Thu, Mar 28, 2019, 8:54 PM Darren Dukes (ddukes) <[email-masked]>
wrote:

> Hi Bob and Ole, as discussed here is the SRH mutability definition text
> with the SRH identified as mutable, with removal of the change bits in the
> TLVs (As AH will just mark the header as 0).
>

I don't understand the motivation for this at all. The implication is that
intermediate devices can arbitrarily rewrite anything in the EH they so
choose. Add/delete options, add/delete SIDs, change routing type, etc. This
is a major divergence from the principles established in RFC8200. Please
explain.

Tom

>
> Hi Ron, since you opened this item, can you ack the closure please – this
> adds the mutability section to the security section.
>
>
>
> <OLD>
>
> 5.4.  AH ICV
>
>
>
> *8.2*
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-16#section-8.2>*.
> Segment Routing Header TLVs Register*
>
>
>
>
>
>    defined in [RFC8126 <https://tools.ietf.org/html/rfc8126>].  Suggested
> registry name is "Segment Routing
>
> *8.2
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-16#section-8.2>.
> Segment Routing Header TLVs Register*
>
>
>
>
>
>    defined in [RFC8126 <https://tools.ietf.org/html/rfc8126>].  Suggested
> registry name is "Segment Routing
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 28 Mar 2019 21:31:42 +0000

Darren,

As I read the proposed text, the entire SRH is mutable, even the Routing Type. I’m pretty sure that that isn’t what you mean to say 😉

                                                            Ron

Juniper Internal
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Thursday, March 28, 2019 8:54 PM
To: Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>; Ole Troan <[email-masked]>
Cc: [email-masked]
Subject: Issue #69 - Ron

<OLD>
5.4.  AH ICV

5.5.  ESP ICV

<OLD>
</OLD>
<NEW>
7.5.  AH ICV computation

<OLD>
8.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Dsegment-2Drouting-2Dheader-2D16-23section-2D8.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=YUg5Yye6vv-35YSPrbLJTnli96-8LZskGPnz8DCQK90&s=_2GBfeyHB7Pg82GIEV4VmMMT6AMDnLGh0RHw5kD8-1I&e=>.  Segment Routing Header TLVs Register

   defined in [RFC8126<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=YUg5Yye6vv-35YSPrbLJTnli96-8LZskGPnz8DCQK90&s=UOCGdNM-IeW6Fk-oIwjzjtPicZM4aQ8QTWtNgKIY65o&e=>].  Suggested registry name is "Segment Routing

8.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Dsegment-2Drouting-2Dheader-2D16-23section-2D8.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=YUg5Yye6vv-35YSPrbLJTnli96-8LZskGPnz8DCQK90&s=_2GBfeyHB7Pg82GIEV4VmMMT6AMDnLGh0RHw5kD8-1I&e=>.  Segment Routing Header TLVs Register

   defined in [RFC8126<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=YUg5Yye6vv-35YSPrbLJTnli96-8LZskGPnz8DCQK90&s=UOCGdNM-IeW6Fk-oIwjzjtPicZM4aQ8QTWtNgKIY65o&e=>].  Suggested registry name is "Segment Routing

Thanks.
  Darren

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 Mar 2019 08:13:14 +0100

Tom,

> On Mar 28, 2019, at 9:25 PM, Tom Herbert <[email-masked]> wrote:
> The 
> On Thu, Mar 28, 2019, 8:54 PM Darren Dukes (ddukes) <[email-masked]> wrote:
> I don't understand the motivation for this at all. The implication is that intermediate devices can arbitrarily rewrite anything in the EH they so choose. Add/delete options, add/delete SIDs, change routing type, etc. This is a major divergence from the principles established in RFC8200. Please explain.

We were discussing mutability in respect to AH.  That is, should AH include the option in its authentication calculation.   The intent was to say that AH would not include the SRH.

Mutability in IPv6 options refers to the data fields changing.  So fields inside of the SRH might change, but SR headers would not be added or deleted.   Nor would the type change.

Thanks,
Bob

> 8.2.  Segment Routing Header TLVs Register
> 
>  
> 
>  
> 
>    defined in [RFC8126].  Suggested registry name is "Segment Routing
> 
> 8.2.  Segment Routing Header TLVs Register
> 
>  
> 
>  
> 
>    defined in [RFC8126].  Suggested registry name is "Segment Routing
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 Mar 2019 10:22:58 +0100

On Fri, Mar 29, 2019, 7:13 AM Bob Hinden <[email-masked]> wrote:

> > I don't understand the motivation for this at all. The implication is
> that intermediate devices can arbitrarily rewrite anything in the EH they
> so choose. Add/delete options, add/delete SIDs, change routing type, etc.
> This is a major divergence from the principles established in RFC8200.
> Please explain.
>
> We were discussing mutability in respect to AH.  That is, should AH
> include the option in its authentication calculation.   The intent was to
> say that AH would not include the SRH.
>

Bob,

Why wouldn't one want to cover immutable fields for auth in SR? RFC8200
already describes how to handle this for DO and HBH.

Tom

> Mutability in IPv6 options refers to the data fields changing.  So fields
> inside of the SRH might change, but SR headers would not be added or
> deleted.   Nor would the type change.
>
> Thanks,
> Bob
>
>
> >
> > Tom
> >
> >
> >
> > Hi Ron, since you opened this item, can you ack the closure please –
> this adds the mutability section to the security section.
> >
> >
> >
> > <OLD>
> >
> > 5.4.  AH ICV
> >
> >
> >