Subject: Comments on < draft-previdi-6man-segment-routing-header-07>

From: Bob Hinden <[email-masked]>
Date: Sat, 1 Aug 2015 13:01:29 -0700

Hi,

A few comments on this draft, I think the w.g. should consider.  Some are editorial, others more serious.

The new draft now includes (as the w.g. requested) the security discussion (in Section 9) that was previously in a separate draft.  I think that improves this document, however, there are still references in to separate draft, for example Section 6.2.1.1 “Security at Ingress” and many other places in the document.  These need to be fixed.  It would probably also be good to move the definition of the HMAC out of the Security Considerations section into the the main part of the draft.

The basic security approach that resolves the issues raised with deprecated RH0 (RFC5095) is the inclusion an HMAC in the routing header.  It covers the Source IP address, First Segment field, octet with clean-up flag, HMAC Key-ID, and all the addresses in the Segment list.   That makes sense.  It verified by the first SR ingress node.  Clearly a better approach than the RH0.   I note that the HMAC does not include the Flow ID even though the document says the HMAC value is unique per flow.

The document includes in a number of places describes actions taken by an SDN controller.  I don’t see any references in the document to how this works.  One simple example, in Section 8, it says “Host A sends a request for a path to server X to the SDN controller or orchestration system”.  There is not any detail on how the host communicates with the SDN controller, nor how the SDN controller communicates with the ingress nodes.  I didn’t see anything in the document (or a reference to another document) how the host would know how to do this.

The HMAC is only verified at the ingress to the SR domain.  It says it doesn’t have to be validated inside the SR domain.  The resulting security model is what I would call “hard exterior, soft interior” or “egg shell” model.  That is if a node inside of the “trusted” SR domain is compromised, all of the problems identified in RFC5095 are possible.  It’s quite well known that this kind of security model is not very strong.

Creating routing headers with many 128bit IPv6 addresses other identifiers, and the HMAC, is going to cause path MTU problems.  The SR header could get very large.  I don’t see any mention of this issue in this draft about this.   This is a serious oversight in my opinion.

Regards,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Aug 2015 22:23:36 +1200

Hi,

Viewed in terms of RFC 6709, this matches several of the criteria to be
considered as a major extension requiring very careful review
(http://tools.ietf.org/html/rfc6709#section-2.1), and
it challenges several of the architectural principles at
http://tools.ietf.org/html/rfc6709#section-3.

I remain of the opinion that this is a hack. When we were working on
RFC 7045, I went through various RFCs very carefully to check on this point.
There is nothing anywhere that allows intermediate nodes to insert headers.
The whole extension header mechanism is designed on the assumption that the
source node creates all headers, and subsequently performs fragmentation if
needed, as well as being responsible for PMTUD of course. But this draft allows
an ingress router to insert a header and an egress router to remove it, not
to mention NATting the destination address. This changes the packet size
(and the payload length) and therefore breaks PMTU and ICMP-error mechanisms.
We simply cannot know whether we have identified all the unintended side
effects of this.

>  The following are the steps of the creation of the SRH:
>
>     Next Header and Hdr Ext Len fields are set according to [RFC2460].
>     Routing Type field is set as TBD (SRH).
>
>     The Segment List is built ...
>
>     The original DA of the packet is encoded as the last segment of
>     the path (encoded in the first element of the Segment List).
>
>     The DA of the packet is set with the value of the first segment
>     (found in the last element of the segment list).

[That's the NAT.]

(etc.)

These are operations that should only be done by the host that creates
the IPv6 packet, which is also the only place that a fragment header
can be included if needed.

I agree that we sometimes specify things that only work within a single
administrative domain, but that has to be spelled out and architecturally clear
at a very early point in the document. I don't want this draft to go forward, but
if it does, it's essential that very tight restrictions are placed on deployment.
There is no real discussion of what an "SR domain" is or how to guarantee that SRH
packets don't escape it, and there is even provision for "Nodes outside of the SR
domain" to generate SRHs. How can that possibly be OK?

On 15/11/2014 14:24, Erik Nordmark wrote:
...
> IPv6 extension headers can only be added together with an outer IPv6 header.
> That ensure that any ICMP errors are sent to the encapsulators, that can 
> regenerate a ICMP error which will have the correct MTU value for the original sender.

Exactly. An encapsulation model would be so much better.

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Aug 2015 17:32:24 +1000

Hi,

> Hi,
<snip>
> Exactly. An encapsulation model would be so much better.

That makes sense to me.

I'd be curious to know why using either a single tunnel with a source
route in the tunnel header, or a series of tunnels representing the
segments isn't possible.

I think it would be simpler to leave the original packet alone and use
it as a tunnel payload, adding or removing a SR tunnel header, rather
than having to perform "shim" type processing on the original packet.
It would also make troubleshooting in the SR domain simpler, because
there would be a clear boundary between what the original host sent,
and what was added when the packet entered the SR domain.

Regards,
Mark.