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

[Joel Halpern <[e-mail]>]

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