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

[Francois Clad <[e-mail]>]

 Hi Andrew,

The originator of an IPv6 packet with a SID in its destination address is
an SR source node per RFC 8754. If this SID is one
of draft-ietf-spring-srv6-srh-compression, then the node must follow the SR
source node specification in section 6 of this document.

I am curious to know which Linux box would verify the upper-layer checksum
of transit packets by default (and drop them if unable to validate it). Can
you share any pointer (e.g., kernel version)?

In my testing on a Linux 5.15 node acting as a software router (default
config with only IPv6 forwarding enabled and a static route), those packets
were forwarded without any issue.

Thanks,
Francois


On 4 Apr 2024 at 16:27:51, Andrew Alston - IETF <[e-mail]>
wrote:

> Francois,
>
>
>
> Node A sends packet to a microsid – without an SRH
>
>
>
>    1. The system by default and in all current implementations will have
>    no way to know it’s a microsid – TX checksumming would therefore break and
>    the packet would be dropped – irrespective of if its on hardware offload to
>    every NIC in existence or if the kernel is doing it – the kernel cannot
>    differentiate between a microsid outbound and a normal ipv6 address
>    2. If you get around (a) then the checksum is invalid in flight until
>    the end node – if you have a software router that is doing RX validation on
>    received packets – which – most linux boxes will do by default – the packet
>    will get dropped
>    3. If you get around (a) and assume that the linux box in question is
>    doing RX HW checksumming – same thing applies – the checksum will be
>    invalid according to the DA – and without an SRH it cannot calculate it
>
>
>
>
>
> This makes this entire thing incompatible with existing deployments of any
> software based routers out there based on bsd, linux and other such kernels
> – and is therefore – a direct violation of the spring charter which says
> that compatibility with existing deployments cannot be affected.
>
>
>
> Andrew
>
>
>
>
>
> * Internal All Employees From: *Francois Clad <[e-mail]>
> *Date: *Thursday, 4 April 2024 at 17:19
> *To: *Andrew Alston - IETF <[e-mail]>
> *Cc: *SPRING WG List <[e-mail]>, Robert Raszuk <[e-mail]>,
> Joel Halpern <[e-mail]>
> *Subject: *Re: [spring] C-SIDs and upper layer checksums
> (draft-ietf-spring-srv6-srh-compression)
>
> 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.
>
>
>
> Andrew,
>
>
>
> What do you mean “in the middle”? Is this software router the SR source
> node, transit node, an intermediate SR segment endpoint, or the last SR
> segment endpoint node by RFC 8754 terminology?
>
>
>
> Thanks,
>
> Francois
>
>
>
> On 4 Apr 2024 at 16:07:31, Andrew Alston - IETF <[e-mail]>
> wrote:
>
> Francois,
>
>
>
> So what happens with software routers in the middle that are doing rx
> offloading? The NIC’s will reject the packets.  And in a pure software
> router by default any software router will see an incorrect checksum – and
> reject the packet.  Because effectively in this case software routers are
> acting as middle boxes.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
>
>
> Internal All Employees
>
> *From: *Francois Clad <[e-mail]>
> *Date: *Thursday, 4 April 2024 at 16:59
> *To: *Andrew Alston - IETF <[e-mail]>
> *Cc: *SPRING WG List <[e-mail]>, Robert Raszuk <[e-mail]>,
> Joel Halpern <[e-mail]>
> *Subject: *Re: [spring] C-SIDs and upper layer checksums
> (draft-ietf-spring-srv6-srh-compression)
>
> 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 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
>
>