Subject: Comment on draft-ietf-6man-segment-routing-header-18

From: Tom Herbert <[email-masked]>
Date: Fri, 5 Apr 2019 16:54:58 -0700

I do not understand neither the requirements nor the motivation for section 7.5.

>From the draft:

"For the purpose of AH ICV calculation the SRH is considered mutable,
with the exception of Next Header, Hdr Ext Len, Routing Type which are
considered immutable."

What does it mean to be mutable for just the purposes of AH ICV?
Either data in packets is mutable in flight or it's not. RFC8200 is
unambiguous in this regard-- mutable fields are not covered by ICV,
non-mutable fields are.

It is not clear what this means to AH ICV calculation, presumably it
means that the whole header is zeroed out for the calculation. This
needs to be clarified.

The only possible motivation I see for this text is to make the whole
SR header header mutable. But there's no restrictions or guidance
here, this implies that an intermediate device may completely rewrite
the segment list and TLVs. The problems of allowing unrestricted
modification of headers created by hosts have been discussed several
times on 6man list. For instance, there is no accountability when
there is a problem. If some intermediate nodes writes bad information
into the routing header that causes the packet to be subsequently
dropped then communications is systematically broken. Even if the
sender gets an ICMP error, it might observe that some changed the data
but has no way to know how to fix the problem or whom to blame.
Modifying data in flight is dangerous without accountability.

In any case, mutability of the segment routing header warrants more
analysis and discussion than just a passing reference in how AH ICV is
processed.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:20:37 +0000

Tom, RFC4302 section 3.3.3.1 suggests new extension headers SHOULD define how IPSec treats the extension header for the purpose of computing an AH ICV.

The text you quote resolves that.

Darren

> On Apr 5, 2019, at 7:54 PM, Tom Herbert <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Apr 2019 08:15:05 -0700

> The text you quote resolves that.
Darren,

The concern isn't about AH ICV handling, it's the implication in the
draft that the whole segment routing header is mutable. There is no
other reference in the draft about mutability in the draft, so the
only conclusion of the reader is that entire segment routing header is
mutable up to the point that the EH length cannot change. And it's not
just data in TLVs that can change, or even TLV types, but in fact
_everything_ including the whole segment list can be rewitten by
intermediate nodes. There raises concerns about robustness and
security of the protocol. As I said in the previous email:

"mutability of the segment routing header warrants more analysis and
discussion than just a passing reference in how AH ICV is processed."

Tom

---

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Apr 2019 09:16:25 -0700

Tom,

> On Apr 8, 2019, at 8:15 AM, Tom Herbert <[email-masked]> wrote:
> 
> discussion than just a passing reference in how AH ICV is processed.”

Please suggest some text.    

Thanks,
Bob

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Apr 2019 09:54:34 -0700

> Please suggest some text.

Bob,

My recommendation on Segment Routing TLVs is unchanged. If they are
necessary then they should have the _same_ format, semantics, and
requirements as HBH and Destination Options. For mutability, this
means that if the third high order bit of the Option Type is set then
the Option Data is mutable. And when an option is marked as mutable
the Option data is zeroed for the purposes of AH ICV computation. In
this manner the sender know exactly what intermediate are allowed to
change and can enforce that the network adheres to the protocol
through the use of AH. This _only_ allows Option data to change in
flight, not Option Types, Option Lengths, nor the Segment list. And
note that if the same format is used, this dramatically simplifies
host implementation since we can reuse the same functions that have be
in place for HBH and Destination Options for many years.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 9 Apr 2019 19:35:24 +0000

Tom, SRH TLV Types are not sharing the same number space as option header TLV types.

In the source routing model the SR Source node knows the capabilities of the segments it places in the SRH, it only adds TLVs relevant to the segments it inserts.
A segment processing TLVs skips types that it does not know or is not configured to process.
Therefor the two upper bits (act bits - what to do when a TLV is unknown) are of no use, as is the chg bit since it’s only useful for AH processing.

If one were to reuse the few lines of code in Linux net/ipv6/exthdrs.c:ip6_parse_tlv, it is easily modified for a new number space and default action at the same time.
Your recommendation does not “dramatically simplifies host implementation” for a Linux host, assuming that’s the host you refer to.

Darren

On Apr 8, 2019, at 12:54 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 8, 2019 at 9:16 AM Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:

Tom,

On Apr 8, 2019, at 8:15 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 8, 2019 at 6:20 AM Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

Bob,

Tom

Thanks,
Bob

Tom

Darren

On Apr 5, 2019, at 7:54 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

From the draft:

Tom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Apr 2019 13:06:02 -0700

Darren,

That's not correct. The point of change bit is that the host indicates
which TLVs may be modified by intermediate nodes (specifically the
Option Data). AH is the mechanism that hosts can use to enforce that
the intermediate nodes don't modify data they aren't supposed to.

In previous versions of the draft, there was a change bit to at least
indicate that TLVs are modifiable. But in the later draft, that was
removed, the AH was modified to ignore the whole segment. Per the
latest draft, the segment routing header IS MUTABLE including all TLVs
and the segment routing list. No explanation or justification how this
is possibly secure or robust has been offered. Please provide that.

Tom

> On Apr 8, 2019, at 12:54 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 9 Apr 2019 20:26:11 +0000

The SRH is secure and robust. 
The header structure is well defined and well reviewed.
The HMAC TLV is defined for validation as required within the SR Domain.

Darren

> On Apr 9, 2019, at 4:06 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Apr 2019 14:10:54 -0700

Darren,

I don't agree. The latest draft eliminates AH security over the SRH.
Without that, the sending host has no way to secure this part of IP
headers. By definition this weakens security. Without this ability,
the network can insert arbitrary bad data into the IP headers with
impunity since there is no paper trail as to who modified the packet.
The only attribution for the modified bits is back to the source
address. I believe this has implications both in operations (breaks
ICMP as I've pointed out previously) but also could have legal
implications (e.g. the inserted data could be illegal content).

> The header structure is well defined and well reviewed.

This comment is in response to a major change in the latest draft
which is in review. I still don't know why this change was made. I
assume the intent is that the whole SRH is modifiable, but that has
not been articulated as the reason.

> The HMAC TLV is defined for validation as required within the SR Domain.

That is insufficient. HMAC TLV is about the network validating the
actions of the host, we need an ability for the host to validate the
actions of the network. The host has vested interest in what happens
to its packets, especially if any in flight modifications are going to
be attributed to it.

Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Apr 2019 23:22:37 +0100

Tom, it's not an implication, it is an explicit statement in section 7.5 of
revision -18.

Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: 08 April 2019 16:15
To: Darren Dukes (ddukes) <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Comment on draft-ietf-6man-segment-routing-header-18

On Mon, Apr 8, 2019 at 6:20 AM Darren Dukes (ddukes) <[email-masked]>
wrote:
>
> Tom, RFC4302 section 3.3.3.1 suggests new extension headers SHOULD define
how IPSec treats the extension header for the purpose of computing an AH
ICV.
Darren,

Tom