On Thu, Jun 13, 2024 at 9:13 AM Andrew Alston - IETF <andrew-ietf=
40liquid.t...@dmarc.ietf.org> wrote:
> Hi All,
>
>
>
> As I have repeatedly stated in spring and will state so again here. In
> certain circumstances the use of C-SID breaks the checksums as relates to
> transit nodes. RFC8200 lays out specific processing rules for upper-layer
> checksums, and expressly deals with scenarios where there is a routing
> header (Section 8.1.). RFC8200 in section 8.1. also provides for specific
> cases for UDP traffic that is encapsulated.
>
>
>
Hi Andrew,
The relevant part of of RFC 8200 for the routing header case appears to be:
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.
This discusses the behavior at the originating node and at the
recipient(s). It does not discuss behavior at the transit nodes.
As you will recall, there have a been a number of community discussions
about processing by middleboxes (including the the taxonomy in RFC 3243,
the UNSAF considerations in RFC 3424, the SEMI workshop reported by RFC
7663, and the PLUS BoF on path signalling which lead to RFC 8558).
Summarizing all of that work in a single email would be impossible, but one
clear result has been a recognition that people have deployed middleboxes
to do lots of different things, not all of them predictable by the
designers of the relevant end-to-end protocol. While we could simply lay
down our tools in the face of that and say that the Internet is now
sufficiently ossified that there will be no change, I think the community
has broadly taken a different approach: note when this might occur and
test to see what mitigations are required. In the case of QUIC, for
example, it was noted that some networks simply did not permit the UDP
packets to pass and so deployments should either provide fallbacks (e.g.
HTTP/2 for HTTP/3 or DNS over TLS instead of DNS over QUIC) or recognize
that some rate of failure will occur.
In this case, the documents note that there may be middleboxes on-path
which compute checksums, and the documents suggest a mitigation (that they
be upgraded to be made aware of C-SIDs) and a warning (that if they are
not, their actions may affect the flow). The need for the warning should
be rare, as it would be quite unusual to deploy both SRv6 and middleboxes
of this type, but it is present for those rare cases. It is certainly
unlikely that this will be a general calamity for operators, as you assert
below, because SRv6 networks are deployed by operators who want those
specific facilities and thus have incentives to avoid this conflicting
behavior.
I don't personally see either the need for more extensive mitigations or a
change to RFC 8200. It is silent on the application of checksum processing
by transit nodes now, and things can proceed without an update taking a
position on the matter.
Just my personal opinion, of course,
regards,
Ted Hardie
As the compression draft notes – there are systems that may be in the
> transit line that will fail to compute the checksums in the absence of a
> routing header. This is in my view a violation of RFC8200. Now, there has
> been some discussion about if “middleware” boxes are bad etc – but that’s
> entirely beside the point, the fact is that the draft changes the data
> plane in such a way as to make it incompatible with existing deployments.
> This brings this clearly into the domain of 6man (since the spring charter
> stated, explicitly, that modification to existing data planes that make
> them incompatible with existing deployments should be avoided)
>
>
>
> I do not want to a start a debate about if what operators have deployed –
> either because they wished to deploy or were forced to deploy by regulation
> – is a good thing – operators are free to run their networks as they see
> fit. However, when changing the ipv6 data plane to the point where a new
> draft makes said data plane incompatible with existent deployments, at the
> very least said draft should update the original draft (and in fact I would
> go further and argue that when changing something as fundamental as the
> upper-layer checksum, there should be an 8200bis to allow for this).
>
>
>
> For far too long we have seen srv6 work violating underlying standards
> that are the domain of 6man – yet we still insist on claiming that srv6 is
> ipv6. This has led to several issues, including the publication of a draft
> like draft-krishnam-6man-sids to clarify things, and a draft in spring to
> address significant security considerations with regards to srv6 etc. The
> time has come to say, we cannot keep violating the base ipv6 standards
> unless we update the original standards – because every time this is
> allowed to happen, we drift further from the base standard and introduce
> the possibility of further calamity for operators. As such – I do not
> believe that this document should be allowed to proceed in the absence of
> an update to RFC8200 and preferably a BIS document. Breaking the checksum
> is simply not acceptable without the base standard explicitly dealing with
> the case in question (as RFC8200 does for other use cases)
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
> Internal All Employees
> From: Alvaro Retana <aretana.i...@gmail.com>
> *Date: *Monday, 3 June 2024 at 15:00
> *To: *6man <i...@ietf.org>
> *Cc: *int-...@ietf.org <int-...@ietf.org>, rtg-...@ietf.org <
> rtg-...@ietf.org>, 6man Chairs <6man-cha...@ietf.org>,
> spring-cha...@ietf.org <spring-cha...@ietf.org>, SPRING WG List <
> spring@ietf.org>
> *Subject: *[IPv6]C-SIDs and Upper-Layer Checksums
> (draft-ietf-spring-srv6-srh-compression)
>
> *Caution:* This email has originated from outside the organization.
> Further it is from a free email service, attackers can use these as
> throwaway accounts. If any doubt, do not reply, click on links, or open
> attachments. You can report the email using the Report Phishing button in
> your Outlook Toolbar. For guidance on how to spot a phishing email refer to
> Protect
> yourself from phishing - Microsoft Support
> <https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44>
>
> Dear 6man WG:
>
> As you may be aware, the spring WG is in the process of advancing
> draft-ietf-spring-srv6-srh-compression [1]. The WGLC discussions have
> resulted in the need to ask you the following questions (see below)
> related to the use/operation of compressed SIDs (C-SIDs).
>
> Please provide any opinions by June 14, 2024.
>
> Thanks!
>
> spring-chairs
>
>
>
> §6.5 (Upper-Layer Checksums) explains how to calculate the Upper-Layer
> Checksum in the presence of C-SIDs. §9.3 (Upper Layer Checksum
> Considerations) discusses the related operational considerations.
> For convenience, both sections are reproduced here:
>
> ===== ===== draft-ietf-spring-srv6-srh-compression-17 ===== =====
>
> 6.5. Upper-Layer Checksums
>
> The Destination Address used in the IPv6 pseudo-header (Section 8.1
> of [RFC8200]) is that of the ultimate destination.
>
> At the SR source node, that address will be the Destination Address
> as it is expected to be received by the ultimate destination. When
> the last element in the compressed SID list is a C-SID container,
> this address can be obtained from the last element in the
> uncompressed SID list or by repeatedly applying the segment behavior
> as described in Section 9.2. This applies regardless of whether an
> SRH is present in the IPv6 packet or omitted.
>
> At the ultimate destination(s), that address will be in the
> Destination Address field of the IPv6 header.
>
> ...
>
> 9.3. Upper Layer Checksum Considerations
>
> Upper layer checksums are computed by the originator of an IPv6
> packet and verified by the ultimate destination(s) as it processes
> the upper layer protocol.
>
> As specified in Section 6.5, SR source nodes originating TCP/UDP
> packets ensure that the upper layer checksum is correctly calculated
> based on the ultimate destination of the session, which may be
> different from the address placed in the IPv6 destination address.
> Such SR source nodes leveraging TCP/UDP offload engines may require
> enhancements to convey the ultimate destination address. These
> implementation enhancements are outside the scope of this document.
>
> It was reported that some network node implementations, including
> middleboxes such as packet sniffers and one software router
> implementation, may attempt to verify the upper layer checksum of
> transit IPv6 packets. These nodes, if deployed inside the SR domain,
> may fail to verify the upper layer checksum of transit SRv6 traffic,
> possibly resulting in dropped packets or in the inability to carry
> out their function. Making these implementations SRv6 aware in
> general or C-SID aware in particular is out of the scope of this
> document.
>
> ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== =====
>
>
> Is this text aligned with §8.1/rfc8200 (Upper-Layer Checksums) [2]?
> Does anything need to be added, deleted, changed, or clarified?
>
> Is using C-SIDs in the above scenarios (§9.3) compatible with IPv6
> transit node deployments compliant with rfc8200?
>
> Does using C-SIDs as specified above represent a modification to the
> IPv6 dataplane? If so, is the modification considered acceptable to
> the WG?
>
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression
>
>
> [2] https://datatracker.ietf.org/doc/html/rfc8200#autoid-17
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests:
> --------------------------------------------------------------------
>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
