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

[Tom Herbert <[e-mail]>]

On Tue, May 28, 2019 at 3:33 AM Ole Troan <[e-mail]> wrote:
>
> Tom,
>
> >> 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.
>
> It seems to me, that what the idea and concept of segment routing is that this header is owned by the network.
> Not the node that encapsulated the user's packet and added the SRH.
> "Dear Mr Network here is a header of scratch space that you can manipulate to your heart's content."
>
> We have added some limitations to that, with definitions of mutability.
> But from that perspective, if I am correct, it is quite meaningless to apply AH.
>
Ole,

AH is only meaningless if end to end security is meaningless in these
networks. If one could _prove_ that _every_ network using segment
routing that exists or ever will exist is _perfectly_ secure because
of perfect filtering and other network mechanisms such the network
_cannot_ in anyway be comprised or misconfigured then, yes, I would
agree that AH is meaningless. Also, in that case HMAC TLV is
meaningless for the same reasons, so it could be removed from the SRH
protocol.

Tom

> Cheers,
> Ole
>
>
>
>
>
>
>
> >
> > Tom
> >
> >> Darren
> >>
> >>
> >>
> >>> On May 24, 2019, at 11:58 AM, Tom Herbert <[e-mail]> 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
> >>> [e-mail]
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>