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

[Francois Clad <[e-mail]>]

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