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

[Brian E Carpenter <[e-mail]>]

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,
> this is not _always_ the case, for instance, we can argue that ESP/AH in
> tunnel mode can be added by a security gateway.

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

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

> 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 ;-)

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

Stefano,

On 11/07/2014 20:35, Stefano Previdi (sprevidi) wrote:

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

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

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.

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

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