Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Francois Clad <[e-mail]>]

 Hi Joel,

One can ping a SID of this document without a segment list by simply
running the ping command with that SID as an argument (2nd paragraph of
section 9.1).

To ping a SID of this document via a SID list, one needs to configure the
originator node to impose that SID list, like any other SRv6 SID list.

Hope this helps.

Cheers,
Francois


On 4 Apr 2024 at 16:29:11, Joel Halpern <[e-mail]> wrote:

> <No Hats>
>
> It seems that the text you quote requires that the ping code or kernel
> code know that the user has specified a uSID for the ping DA.   Maybe I am
> missing something, but it is not obvious to me how that would be achieved?
> And does seem to imply that an unmodified ping will get incompatible and
> unexpected results?
>
> Yours,
>
> Joel
> On 4/4/2024 10:23 AM, Francois Clad wrote:
>
> Hi Joel,
>
> The ping behavior is described in section 9.1 of the draft (
> https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-14.html#section-9.1
> ).
>
> Specifically,
> "When pinging a SID of this document via a segment list, the SR source
> node MUST construct the IPv6 packet as described in Section 6 and compute
> the ICMPv6 checksum as described in Section 6.5."
>
> Please let me know if anything in this text is not clear.
>
> Thanks,
> Francois
>
> On 4 Apr 2024 at 16:10:11, Joel Halpern <[e-mail]>
> wrote:
>
>> <No Hat>
>>
>> Does this mean that if I have a source and destiantion host inside an
>> SRv6 domain, and I am trying to verify a uSID path between them, so I issue
>> the command ping <usUD-DA>, it will fail?  Given that we have documents
>> describing the use of ping and traceroute with SRv6, shouldn't the
>> comrpession document say someething about this?
>>
>> Your,s
>>
>> Joel
>> On 4/4/2024 9:59 AM, Francois Clad wrote:
>>
>> Hi Andrew,
>>
>> The originator (TX Linux box in your case) acting as an SR source node
>> for C-SID must follow the entire Section 6 of
>> draft-ietf-spring-srv6-srh-compression, including section 6.5 about the
>> checksum calculation. One cannot expect it to work if it only implements
>> half of it.
>>
>> On the receive side, there is nothing special to do. The DA in the
>> received IPv6 header is the one that was used for the checksum calculation.
>>
>> I do not see anything broken.
>>
>> Cheers,
>> Francois
>>
>> On 4 Apr 2024 at 15:32:12, Andrew Alston - IETF <[e-mail]>
>> <[e-mail]> wrote:
>>
>>> So in investgiating this further, there is a further problem.
>>>
>>>
>>>
>>> I’ve checked on 4 different linux boxes with 4 different network cards.
>>>
>>>
>>>
>>> Linux by default offloads TX checksumming on a lot of network cards.  If
>>> you originate a packet with a microsid and no SRH – and the linux box
>>> offloads the checksum generation – the checksum generated by the NIC will
>>> be incorrect – and when the packet arrives at the end host – if that end
>>> host is running RX checksumming – the checksum will fail and the packet
>>> will be dropped.
>>>
>>>
>>>
>>> If you disable TX checksumming – the kernel will have no way to tell if
>>> the packet is an Ipv6 or a microsid packet, it will therefore use the DA –
>>> and generate an incorrect checksum.  Again – if RX checksumming is enabled
>>> on the receiving end point – the packet will get dropped.
>>>
>>>
>>>
>>> Effectively this does NOT just affect middle boxes – it effects anything
>>> generating a packet directed to a microsid that either offloads the tx to
>>> hardware (whichi will have no clue this is a microsid) or in the
>>> alternative is generating tx checksums itself via kernel mechanisms that
>>> will treat these packets as standard Ipv6 packets.
>>>
>>>
>>>
>>> This is broken – severely broken.
>>>
>>>
>>>
>>> Andrew
>>>
>>>
>>>
>>>
>>>
>>> * Internal All Employees From: *spring <[e-mail]> on
>>> behalf of Francois Clad <[e-mail]>
>>> *Date: *Thursday, 4 April 2024 at 14:49
>>> *To: *Joel Halpern <[e-mail]>
>>> *Cc: *SPRING WG List <[e-mail]>, Robert Raszuk <[e-mail]
>>> >
>>> *Subject: *Re: [spring] C-SIDs and upper layer checksums
>>> (draft-ietf-spring-srv6-srh-compression)
>>>
>>> Some people who received this message don't often get email from
>>> [e-mail]. Learn why this is important
>>> <https://aka.ms/LearnAboutSenderIdentification>
>>>
>>> CAUTION: This email has originated from a free email service commonly
>>> used for personal email services, please be guided accordingly especially
>>> if this email is asking to click links or share information.
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> Section 6.5 of draft-ietf-spring-srv6-srh-compression specifies how an
>>> SR source node originating a packet with an upper layer checksum determines
>>> the Destination Address for use in the IPv6 pseudo-header.
>>>
>>>
>>>
>>> As a co-author, I’d say that the current text of 6.5 is good.
>>>
>>>
>>>
>>> This text is aligned with RFC 8200. It only indicates how the text in
>>> Section 8.1 of RFC 8200 applies to the SIDs of
>>> draft-ietf-spring-srv6-srh-compression. This is necessary since RFC 8200
>>> does not specify the format nor behavior of any source routing scheme.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Francois
>>>
>>>
>>>
>>>
>>>
>>> On 4 Apr 2024 at 00:10:55, Joel Halpern <[e-mail]>
>>> wrote:
>>>
>>> I can not speak to the "norm" for other working groups.  The SPRING
>>> charter is very specific about what we have to do if we want to change an
>>> underlying protocol.  We have to go back to the WG which owns that
>>> protocol.
>>>
>>> 6man gets to decide if the change is acceptable, and if it is acceptable
>>> how it is to be represented.  SPRINGs job is to make sure we are asking the
>>> question we intend.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 4/3/2024 6:05 PM, Robert Raszuk wrote:
>>>
>>> Ok Joel,
>>>
>>>
>>>
>>> Thank you for this clarification.
>>>
>>>
>>>
>>> To me the actual spirit of RFC8200 8.1 is to say that it is ok to
>>> compute the checksum by the src such that it comes out right at the final
>>> destination.
>>>
>>>
>>>
>>> But I guess we can have different opinions about that.
>>>
>>>
>>>
>>> But what I find specifically surprising here is that it is a norm in
>>> IETF to have new specifications defining protocol extensions and their
>>> behaviour and never go back to the original protocol RFC to check if this
>>> is ok or not. If that would not be a normal process I bet we would still be
>>> using classful IPv4 routing all over the place.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Robert
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 3, 2024 at 11:28 PM Joel Halpern <[e-mail]>
>>> wrote:
>>>
>>> The concern with regard to the text that the chairs are asking about is
>>> not about intermediate nodes verifying the checksum.  The text does not
>>> talk aabout that, so we are not asking about that.
>>>
>>> But, the text in 8200 specifies how the originating node is to compute
>>> the upper layer checksum.  It doesn't say "do whatever you need to do to
>>> make the destination come out right".  It provides specific instructions.
>>> Yes, it is understandable that those instructions do not cover the
>>> compressed container cases.  Which is why the compression document
>>> specifies changes to those procedures.
>>>
>>> Thus, we need to ask 6man how they want to handle the change in the
>>> instructions in 8200.
>>>
>>> the question we are asking SPRING is whether there is any clarification
>>> people want to the text in the compression draft before we send the
>>> question over to 6man.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 4/3/2024 5:15 PM, Robert Raszuk wrote:
>>>
>>> Hi Joel,
>>>
>>>
>>>
>>> My interpretation of text from RFC8200 is that it allows discrepancy
>>> between the header and the upper layer checksum as long as final packet's
>>> destination sees the correct one.
>>>
>>>
>>>
>>> The last condition is met.
>>>
>>>
>>>
>>> So I see no issue.
>>>
>>>
>>>
>>> Sure RFC8200 does not talk about SRH nor cSIDs, but provides a hint on
>>> how to handle such future situations.
>>>
>>>
>>>
>>> With that being said I would like to still understand what real problem
>>> are we hitting here ...
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Robert
>>>
>>>
>>>
>>> On Wed, Apr 3, 2024 at 11:09 PM Joel Halpern <[e-mail]>
>>> wrote:
>>>
>>> There are two cases covered in section 6.5 of the compression draft that
>>> appear to be at variance with secton 8.1 of RFC 8200.
>>>
>>> First, if the final destination in the routing header is a compressed
>>> container, then the ultimate destination address will not be the same as
>>> the final destination shown in the routing header.
>>>
>>> Second, if a uSID container is used as the destination address and no
>>> SRH is present, then in addition to the above problem there is no routing
>>> header to trigger the behavior described.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 4/3/2024 4:22 PM, Robert Raszuk wrote:
>>>
>>> Hi Alvaro,
>>>
>>>
>>>
>>> Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the
>>> behavior when an originating node inside an SRv6 domain creates a
>>> packet with a C-SID as the final destination.
>>> *This description differs from the text in Section 8.1 of RFC8200.*
>>>
>>>
>>>
>>> I would like you to clarify the above statement - specifically of the
>>> last sentence.
>>>
>>>
>>>
>>> Reason for this that after looking at both drafts I find section 6.5 of
>>> the subject draft to be exactly in line with RFC8200 section 8.1 especially
>>> with the paragraf which says:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *         If the IPv6 packet contains a Routing header, the Destination
>>>          Address used in the pseudo-header is that of the final
>>>  destination.  At the originating node, that address will be in
>>>  the last element of the Routing header; at the recipient(s),          that
>>> address will be in the Destination Address field of the          IPv6
>>> header.*
>>>
>>>
>>>
>>> So before we dive into solutions (as Andrew has already provided a few
>>> of) I think we should first agree on what precise problem are we solving
>>> here ?
>>>
>>>
>>>
>>> Many thx,
>>>
>>> Robert
>>>
>>>
>>>
>>> PS. As a side note I spoke with my hardware folks - just to check if
>>> validation of upper-layer checksum is even an option for transit nodes. The
>>> answer is NO as most data plane hardware can read at most 256 bytes of
>>> packets. So unless there is some specialized hardware processing up to 9K
>>> packets in hardware at line rates this entire discussion about checksum
>>> violations, fears of firing appeals is just smoke.
>>>
>>>
>>>
>>> _______________________________________________
>>> spring mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>>