Re: Applicability of AH in draft-ietf-6man-segment-routing-header-19

This text was sent to the list and had support in April.
It's part of the consensus reached around not defining AH processing in the draft.

Darren

> On May 24, 2019, at 11:58 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> Hello,
> 
>> From section 7.5:
> "The SR Domain is a trusted domain, as defined in [RFC8402] Section 2
> and Section 8.2.  The SR Source is trusted to add an SRH (optionally
> verified via the HMAC TLV in this document), and segments advertised
> within the domain are trusted to be accurate and advertised by trusted
> sources via a secure control plane.  As such the SR Domain does not
> rely on the Authentication Header (AH) as defined in [RFC4302] to
> secure the SRH."
> 
> This is misleading on several fronts.
> 
> First, this equates a trusted SR Domain as being a guaranteed secured
> domain. It's not. Even RFC8402 says: "The use of best practice to
> reduce the risk of tampering within the trusted domain is important.".
> So security mechanisms within the IP protocols are still required.
> 
> Secondly, this seems to somehow equate HMAC TLV functionality with AH.
> They are not equivalent. AH is end-to-end authentication and covers
> all extension headers and the IP header, HMAC TLV only covers select
> fields in SRH and is end-to-something where there is no guidance
> offered as to what that "something" is supposed to be (this is
> precarious in itself since it allows valid configurations where
> sources are setting HMAC TLV, but nobody in the path actually is
> verifying it leading to a false sense of security). If anything, AH is
> a superset of HMAC TLV.
> 
> So, I don't see any argument here that AH is any more unneeded in an
> SR domain versus any other network, nor any argument that HMAC TLV is
> somehow superior to AH for security in an SR domain. I suggest to
> remove this whole paragraph and just keep the next paragraph that AH
> will be defined in other documents. Let users decide what security
> measures (AH, HMAC TLV, edge filtering, etc.) are appropriate for
> their paritcular network...
> 
> Tom
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------