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

[Bob Hinden <[e-mail]>]

Stefano,

> On Sep 1, 2015, at 12:55 PM, Stefano Previdi (sprevidi) <[e-mail]> wrote:
> 
> Hi Bob,
> 
> thanks for your comments, see below...
> 
> On Aug 1, 2015, at 10:01 PM, Bob Hinden <[e-mail]> wrote:
>> 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.
> 
> 
> I agree. The request of merging the two drafts has been fulfilled rapidly and some obvious editing work needs to be done in order to properly incorporate the security draft into the SRH one. We're working on this.

Good.

> 
> 
>> 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.
> 
> 
> well, this is part of the SDN model and its northbound APIs. Clearly, is out of the scope of the SRH draft.

My point is that is says that a host is supposed to do this, but there isn’t even a reference to what it should do.  In other words, on one could not implement this from this draft.

> 
> 
>> 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.
> 
> 
> this is how most of the networks are operated today. All the security mechanisms are implemented at the edge and very little is replicated in the core so to keep the core as light as possible in its configuration. In this respect, SRH doesn't add/remove anything to the existing model.

You are making a very broad statement, but IMHO it is broken.  We should not be designing new mechanisms that have weak security.

> 
> 
>> 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.
> 
> 
> Well, the mtu issue has been raised since the early days of tunneling so again here nothing new. Having said that, we can certainly add some text in order to illustrate how an operator can safely run encapsulation methods increasing packet size without breaking traffic flows (e.g. mpls).
> 
> Now, I take the proposal of restricting the srh insertion at the source, which allows a transit router to do insertion through the addition of an outer ipv6 header.

That would help, and if the issue was discussed in the draft.

> 
> So, my proposal is to:
> . restructure the content of the draft, focus on header format and operations
> . describe the operational model: srh insertion/removal, definition of sr-domain

I think RFC6554 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)” is a good model for how to do new SR headers.  I suggest you take a look and rework your document to follow the way RFC6554 resolved the issues.

Bob