Re: L4 Checksum and draft-ietf-6man-segment-routing-header

On 17 May 2016 at 21:23, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:
>
>
> Le 15/05/2016 à 12:04, Tal Mizrahi a écrit :
>>
>> Hi,
>>
>>
>>
>> [Apologies if this issue has been discussed before.]
>>
>>
>>
>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment
>> Endpoint Node’ updates the Destination IP address.
>>
>>
>> Therefore, it must also update the Layer 4 Checksum, right?
>
>
> I guess yes.  I guess the draft assumes that only the end nodes create
> and verify the checksum value.
>

It isn't an assumption, it is the way IPv6 works.

End-to-end checksums like the TCP or UDP ones are only calculated or
verified at the ends.

If the packet is mis-delivered to an upper layer TCP or UDP for one of
the intermediary DA hops, the packet will be thrown away because the
upper layer checksum validation should. If it was changed as the
intermediary DAs were swapped, then the packet could be considered
legitimate by intermediate TCP or UDP, and the could then payload
handed up to an application that wasn't expecting it at all.

Briefly looking at the SR draft, the SRH processing looks to be the
same or similar to the original IPv6 routing header.

https://tools.ietf.org/html/rfc2460#section-4.4

> (whether that is done correctly it is another matter;
> draft-ietf-6man-segment-routing-header-01 tells that there are two
> different ways of inserting an SRH: by the end nodes _or_ by
> intermediary nodes; if it is done by the intermediary nodes there is a
> need to make sure that overall the SRH concept makes sense).
>
>> I wonder if there is an upper bound on the size of the SRH.
>
>
> I think that size can be deduced from the length of the Hdr Ext Len
> field of draft-ietf-6man-segment-routing-header-01: 8 bits would mean
> the max size is 256 bytes (plus 1 by its definition).
>
> One may wonder though whether there can be multiple SRHs in a packet?
>
>> Otherwise, the L4 Checksum may be located in a pretty deep location.
>>
>> Speaking from a chip vendor’s perspective this may be a problem.
>

Which is why EHs are not intended to be examined or processed by
intermediate nodes, with exception to one of them, and that one is
always the first EH if present. Required processing of that is being
loosened a bit in:

IPv6 Hop-by-Hop Options Extension Header
https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03

Regards,
Mark.

>
> I think that is understandable.
>
> Alex
>
>>
>>
>>
>> Thanks,
>>
>> Tal Mizrahi.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------