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

[Tom Herbert <[e-mail]>]

On Tue, May 17, 2016 at 4:49 AM, Mark Smith <[e-mail]> wrote:
> On 17 May 2016 at 21:23, Alexandre Petrescu
> <[e-mail]> 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.
>
There are some host optimizations like checksum offload and
segmentation offload that are performed before the stack would set the
final address in the destination. If the checksum is not correct on
the wire for the addresses in the packet these optimizations can't be
used (but packets should not be dropped). In ILA we do a checksum
neutral translation that keeps the checksum correct and does not
require middelboxes to update L4 checksum fields.

Tom

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