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

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 1 Sep 2015 09:55:24 +0000

Hi Bob,

thanks for your comments, see below...

On Aug 1, 2015, at 10:01 PM, Bob Hinden <[email-masked]> 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.

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

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

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

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

s.

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 1 Sep 2015 09:55:27 +0000

On Aug 2, 2015, at 12:23 PM, Brian E Carpenter <[email-masked]> wrote:

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

that is fine by me.

We can specify that the source inserts the SRH. This means that, in a SR domain, an ingress node would encap the received packet into an outer ipv6+srh header. This model works for me.

s.

> Regards
>   Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Sep 2015 07:09:28 -0300

Hi, Stefano,

On 09/01/2015 06:55 AM, Stefano Previdi (sprevidi) wrote:
>> 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.
>> 
> We can specify that the source inserts the SRH. This means that, in a
> SR domain, an ingress node would encap the received packet into an
> outer ipv6+srh header. This model works for me.

FWIW, I think that would be a better approach.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Sep 2015 12:43:58 +1000

> FWIW, I think that would be a better approach.

Also FWIW, I agree too. Much clearer boundary between what the
originating host created and what the SR domain has added, meaning
much easier troubleshooting.

Regards,
Mark.

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 2 Sep 2015 09:03:03 +0000

Hi Stefano,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Stefano Previdi
> (sprevidi)
> Sent: Tuesday, September 01, 2015 5:55 PM
> To: Brian E Carpenter
> Cc: 6man
> Subject: Re: Comments on < draft-previdi-6man-segment-routing-header-07>
> 
> 
> > 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
> > 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.

[Will] Agree to what Brian concerned about here.

> We can specify that the source inserts the SRH. This means that, in a SR
> domain, an ingress node would encap the received packet into an outer
> ipv6+srh header. This model works for me.
> 
[Will] Inserting a SRH (comparing to encapsulating the original packet) at the ingress node of the SR domain seems rather controversial.

However, IMHO, this alternative approach you described seems to be capable to solve this issue, and most/all of the technical issues that have been raised. So I support this change.

Regards,
Will

---

From: Bob Hinden <[email-masked]>
Date: Wed, 2 Sep 2015 14:32:06 +0300

Stefano,

> On Sep 1, 2015, at 12:55 PM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 
> Hi Bob,
> 

Good.

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

> 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 it…

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

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

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