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

On Mon, May 27, 2019 at 10:40 AM Darren Dukes (ddukes) <ddukes@cisco.com> wrote:
>
> 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.
>
Darnen,

Nevertheless, it is still misleading and not relevant to the normative
requirements of the document. I believe this paragraph can simply be
removed without loss of content or clarity.

Tom

> 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
> > --------------------------------------------------------------------
>