Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)
"jmh.direct" <jmh.direct@joelhalpern.com> Thu, 04 April 2024 17:26 UTC
Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC9EC14F600 for <spring@ietfa.amsl.com>; Thu, 4 Apr 2024 10:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.794
X-Spam-Level:
X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofSmdQN8w5NT for <spring@ietfa.amsl.com>; Thu, 4 Apr 2024 10:26:28 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A059EC14F5FA for <spring@ietf.org>; Thu, 4 Apr 2024 10:26:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4V9T781Nwbz1ntl7; Thu, 4 Apr 2024 10:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1712251588; bh=IZUaxG/lCdwEpQpMjk+QYsFvClbUvyx7GAgwnsTx5XU=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=hLKUqlqA1YCqBnEWzq6VkUMd5zUihrd27thCGTHLWqjFi+e1XLrT75aJKUib6qo+t NMNEPEYBBI75rTM6gaS835TkLrTnBj99xWGQA+E+8kVXiFX6Upq+o3SWknXqxQTTCs eEcW+ujRIK8bKx5l5zXW9GMovw7XnYN9j9ay4aDQ=
X-Quarantine-ID: <qvK7U-1MMawG>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [IPv6:2600:381:4311:be38:b935:a849:71da:1452] (unknown [IPv6:2600:381:4311:be38:b935:a849:71da:1452]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4V9T74452Sz1nsk5; Thu, 4 Apr 2024 10:26:24 -0700 (PDT)
SavedFromEmail: jmh.direct@joelhalpern.com
Date: Thu, 04 Apr 2024 13:26:22 -0400
In-Reply-To: <CAHT6gR84V9w5Htp7sQ67iu7+X8esohKOUE99gVbbZfZeLqyEGw@mail.gmail.com>
Importance: normal
From: "jmh.direct" <jmh.direct@joelhalpern.com>
To: Francois Clad <fclad.ietf@gmail.com>
Cc: SPRING WG List <spring@ietf.org>, Robert Raszuk <robert@raszuk.net>, Andrew Alston - IETF <andrew-ietf@liquid.tech>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1149277648923550"
Message-Id: <4V9T74452Sz1nsk5@mailb2.tigertech.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/IlnDZrKr6Y8s2pAvYCua07KCOso>
Subject: Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 17:26:33 -0000
So you can't ping a uSID list by just specifying the uSID as the DA?Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
-------- Original message --------From: Francois Clad <fclad.ietf@gmail.com> Date: 4/4/24 1:10 PM (GMT-05:00) To: Joel Halpern <jmh.direct@joelhalpern.com> Cc: SPRING WG List <spring@ietf.org>, Robert Raszuk <robert@raszuk.net>, Andrew Alston - IETF <andrew-ietf@liquid.tech> Subject: Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)
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 <jmh.direct@joelhalpern.com> 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 <jmh.direct@joelhalpern.com>
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 <andrew-ietf@liquid.tech>
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
<spring-bounces@ietf.org>
on behalf of Francois Clad <fclad.ietf@gmail.com>
Date: Thursday, 4 April 2024
at 14:49
To: Joel Halpern <jmh.direct@joelhalpern.com>
Cc: SPRING WG List <spring@ietf.org>,
Robert Raszuk <robert@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.ietf@gmail.com.
Learn
why this is important
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.direct@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
<jmh@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
<jmh@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
- [spring] C-SIDs and upper layer checksums (draft-… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Alvaro Retana
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… jmh.direct
- Re: [spring] C-SIDs and upper layer checksums (dr… Andrew Alston - IETF
- Re: [spring] C-SIDs and upper layer checksums (dr… Cheng Li
- Re: [spring] C-SIDs and upper layer checksums (dr… Martin Vigoureux (Nokia)
- Re: [spring] C-SIDs and upper layer checksums (dr… Cheng Li
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Antoine FRESSANCOURT
- Re: [spring] C-SIDs and upper layer checksums (dr… Martin Vigoureux (Nokia)
- Re: [spring] C-SIDs and upper layer checksums (dr… Tal Mizrahi
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Ketan Talaulikar
- Re: [spring] C-SIDs and upper layer checksums (dr… Boris Hassanov
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] C-SIDs and upper layer checksums (dr… Ketan Talaulikar
- Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper … Shah, Himanshu
- Re: [spring] C-SIDs and upper layer checksums (dr… Joel Halpern
- Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper … Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Francois Clad
- Re: [spring] C-SIDs and upper layer checksums (dr… liu.yao71
- Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper … Mark Smith
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… Robert Raszuk
- Re: [spring] C-SIDs and upper layer checksums (dr… linchangwang
- Re: [spring] C-SIDs and upper layer checksums (dr… liu.yao71
- Re: [spring] C-SIDs and upper layer checksums (dr… 梁艳荣