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 <spring-boun...@ietf.org> on behalf of Francois Clad
<fclad.i...@gmail.com>
*Date: *Thursday, 4 April 2024 at 14:49
*To: *Joel Halpern <jmh.dir...@joelhalpern.com>
*Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk
<rob...@raszuk.net>
*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
fclad.i...@gmail.com. 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
<jmh.dir...@joelhalpern.com> 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
<j...@joelhalpern.com> 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
<j...@joelhalpern.com> 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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
