Chairs conclusions Re: SRH Mutability and AH

[Bob Hinden <[e-mail]>]

Ole and I have reviewed the discussion in response to our question.  There isn’t an approach that everyone agrees too, but we came to several conclusions.

1) The SRH draft should clearly specific which SRH fields are mutable, non-mutable, and/or predictable to be consistent with RFC8200.   We don’t think the current draft is clear, some of the changes introduced -18 made the problem worse (for example, removing the change flag from the TLV definition in Section 2.1, and the new AH text).   Having this part of the specification be clear is good practice to achieve interoperability.   We don’t see any downside to doing this.

2) We don’t think the document needs to specify how AH should work with SRH.  Once 1) is resolved, it should be possible to have AH work with SRH, but that is out of scope for this document.   The SRH draft can say that defining how AH works with SRH is out of scope and may be define elsewhere.   If there are people who would like to define this, they can write a separate draft.

We would like to see a -19 published with these changes.   Once this is out, we will start a two week working group last call on the new draft.   There are two open issues in the tracker, we think the #69 will be resolved by 1), the other (#67) can be raised during the w.g. last call if still appropriate.

There is not a solution here that makes everyone happy, but we think this is a reasonable position that should allow the document to advance.

Thanks,
Bob & Ole



> On Apr 13, 2019, at 9:14 AM, Bob Hinden <[e-mail]> wrote:
> 
> Reading the email thread and looking the new draft <draft-ietf-6man-segment-routing-header-18> as compared the previous version <draft-ietf-6man-segment-routing-header-17>, we would like the working group view on AH and mutability of SRH and its TLVs.
> 
> In the context of AH and ICV calculation, there are essentially 3 options:
> 
> 1) Say nothing at all. Similar to the RFC6554 approach.
>   While unstated, an AH ICV implementation would likely have considered it mutable but
>   predictable as RH0
> 
>  Consequence for the draft:
>   - Remove section 7.5 in -18.
> 
> 2) Whole header content mutable
>   Current revision -18. AH ICV zeroes out the full content of the SRH.
>   Neither SID list nor TLVs are protected.
>   See section 7.5 in -18.
> 
> 3) Predictable and mutable
>   Very close to revision -17.
>   TLVs have a flag like HBH/Dest option stating if the option can change en route.
>   Both SID list and immutable TLVs are protected by AH.
> 
>   Aligned with RFC8200, RH0, RFC4302
> 
>   Implications for the draft:
>   Put back the following text from -17:
> 
> ------------
> Section 2.1 SRH TLVs
> 
> TLVs may change en route at each segment.  To identify when a TLV
> type may change en route the most significant bit of the Type has the
> following significance:
> 
>    0: TLV data does not change en route
> 
>    1: TLV data does change en route
> 
> Identifying which TLVs change en route, without having to understand
> the Type, is required for Authentication Header Integrity Check Value
> (ICV) computation.  Any TLV that changes en route is considered
> mutable for the purpose of ICV computation, the Type Length and
> Variable Length Data is ignored for the purpose of ICV Computation as
> defined in [RFC4302].
> 
> Section 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.
> ----------------
> 
> We have questions about these changes in -18. Given the limited domain applicability of this option, it might be unlikely that AH will ever be used. But even so, there might be value in explicit signaling of which parts of SRH and TLVs are changeable en route and which ones aren’t.
> 
> What is the working groups view? Is it important to specify integrity protection for the SID list and TLVs? Or given the controlled domain expectations can it be left without?
> 
> Thanks,
> Bob & Ole
> 
>