Subject: Re: I-D Action: draft-vyncke-6man-segment-routing-security-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jul 2014 15:30:47 +1200

Hi,

This draft says:

>    The SRH is simply another version of the routing header as described
>    in [RFC2460] and is:
> 
>    o  inserted when entering the segment routing domain which could be
>       done by a node or by a router;

There is no provision for routers to insert headers in an IPv6 packet,
because this changes the packet size (and the payload length) and
therefore breaks PMTU mechanisms. Only the host that originates a packet
can insert headers.

It seems that draft-previdi-6man-segment-routing-header-01 has the
same problem. It says:

>    When creating the SRH (either at ingress node or in the SDN
>    controller) the following is done:
> 
>       Next Header and Hdr Ext Len fields are set according to [RFC2460].
> 
>       Routing Type field is set as TBD (SRH).
> 
>       The DA of the packet is set with the address of the FIRST segment
>       of the path.

(etc.)

These are operations that can 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. As I understand it, the "ingress node" is
a router, not the originating host. So this seems to be broken.

   Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 11 Jul 2014 07:54:28 +0000

Brian

Thanks for your review.

You are right extension headers are _usually_ inserted by the source. But,
this is not _always_ the case, for instance, we can argue that ESP/AH in
tunnel mode can be added by a security gateway.

So, inserting a SRH is not that exceptional. Of course, special care must
be taken for MTU but in the use case this would not be a problem as SRH is
used mainly within a single operator, so, a prerequisite is to have a
larger MTU on all internal links.

Note: I just quickly read again RFC 2460, and, I did not find any place
where it is specified that extension header must be inserted only by the
source. If my reading is wrong, then this is another reason to propose
this I-D to 6MAN ;-)

-éric

On 11/07/14 05:30, "Brian E Carpenter" <[email-masked]> wrote:

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 11 Jul 2014 08:35:42 +0000

> a router, not the originating host. So this seems to be broken.

well, unless the multiple interoperable implementations we have are 
also broken, I can tell you (and show you) it's a reality that works 
well, that address a set of requirements (especially in terms of 
service chaining) and "routers" can happily insert extensions headers.

Now, let's agree on the definition of "router". If it's a device 
acting at layer 3 and that "routes" packets based on DA and FIB 
instructions, then it is obvious that a router can insert an SRH.

However, it is also obvious that we do not expect core routers do so.

s.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jul 2014 08:50:09 +1200

Eric,

On 11/07/2014 19:54, Eric Vyncke (evyncke) wrote:
> Brian
> 
> Thanks for your review.
> 
> You are right extension headers are _usually_ inserted by the source. 

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 mechanism
is designed on the assumption that the source node creates all
headers, and performs fragmentation if needed, as well as being
responsible for PMTUD of course.

> But,

Tunnel mode is irrelevant, because the outer header (that
includes an IPsec header) encapsulates the inner header,
which is unchanged. It's very clear in section 5.1.2.2 of
RFC 4301. (There are two fields in the inner header, ECN
and hop limit, that get updated by the decapsulator.)

> So, inserting a SRH is not that exceptional. 

On the contrary, it's completely exceptional.

> Of course, special care must

"Mainly" is not good enough. 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.

> source. If my reading is wrong, then this is another reason to propose

It's true that it isn't stated in those words. It's just clearly implied.

Stefano,

> On Jul 11, 2014, at 5:30 AM, Brian E Carpenter wrote:

...
> service chaining) and "routers" can happily insert extensions headers.

Well, it would be interesting to know how those implementations
work when there is a marginal MTU inolved and/or when the hosts
are using IPsec. It doesn't alter the fact that as far as the
design of IPv6 extension headers goes, this is a hack.

> instructions, then it is obvious that a router can insert an SRH.

No it isn't; it's obvious that routing headers were designed to
be created by the originating host, before calculating the payload
length and before deciding whether a fragment header is needed.

I can imagine in an SDN context that the source host is
instructed by the SDN controller to insert a specific SRH.
I can imagine a model where the source host includes an
blank SRH that can be updated by the ingress router.
But the model suggested in these two drafts where an ingress
router inserts an SRH is definitely incompatible with RFC 2460.

    Brian