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

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" <brian.e.carpenter@gmail.com> wrote:

>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
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------