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

From: Tom Herbert <[email-masked]>
Date: Fri, 24 May 2019 08:58:26 -0700

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 27 May 2019 17:40:26 +0000

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 <[email-masked]> wrote:
> 
> Hello,
> 
>> From section 7.5:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 May 2019 12:00:36 -0700

> 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

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 12:33:38 +0200

Tom,

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

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 May 2019 10:01:25 -0400

If the working group wants to write that the SRH is generally fully 
mutable, with restrictions on what specific nodes are permitted to do, 
that would be a clear statement.
If the authors wrote that, and the working group agreed to it, then we 
would have met the request from the chairs that the document be clear 
about mutability.

But currently, the document tries to walk some middle ground that I cna 
not understand.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 09:00:23 -0700

> 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

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 19:04:57 +0200

Tom,

> meaningless for the same reasons, so it could be removed from the SRH

If I understand the typical use cases correctly, there isn't really an end to end here.
There is middle to middle, as in packet passes through a limited domain that encapsulates the user's packet in a new IPv6 header and an SRH header.
Where that limited domain is reasonably free to do whatever it needs to do with that header.
Imagining devices doing forwarding of this at terabit speeds verifying AH seems indeed quite far fetched.
And of questionable value too.

At least I, do not see that this is worth spending time on. Especially since AH isn't deployed for the use cases it was intended for either.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2019 19:16:39 +0200

Joel,

> If the working group wants to write that the SRH is generally fully mutable, with restrictions on what specific nodes are permitted to do, that would be a clear statement.
> If the authors wrote that, and the working group agreed to it, then we would have met the request from the chairs that the document be clear about mutability.
> 
> But currently, the document tries to walk some middle ground that I cna not understand.

What puzzles me a little, is why does it matter?
The protocol must be written to be interoperable. And it's not clear to me if describing this differently in this document would affect that.
And if it is to restrict future documents, then sure we can give guidance of that specifications of new SIDs must describe their mutability properties, but outwith that, it's hard to control the what future documents does.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 10:50:20 -0700

Ole,

Your comments are based about assumptions in the expected use case.
That's not a necessary consideration in normative protocol
requirements. IP protocols are built to be robust and secure across
different use cases, even those not envisioned by the designers when
the protocols are conceived. I don't believe segment routing warrants
an exception to that principle. So if someone someday finds themselves
in an environment where they want to use segment routing and
authentication header simultaneously, it's not IETF's prerogative to
tell them that they're wrong; it is our prerogative to define the IP
protocols to ensure they can robustly work together.

In any case, the consensus of the WG is that the interaction between
AH and SR would be defined in other documents. I've posted that in
draft-herbert-ipv6-srh-ah-00 (please take a look at it). Assuming we
can nail down he mutability of SRH, specifying and implementing the
protocol is not difficult.

Tom