I think it’s only fair to clarify my remarks – again – speaking entirely as a
contributor.
Let’s be clear – the middlware boxes will work in most cases – except when
there is no SRH.
The problem here is that if you apply a Micro-SID – which is imposed by
originating system – and have no SRH – the DA of the packet is changing along
the way – and the L4 checksum will be broken. There is no way to actually
calculate the correct L4 checksum in flight – and in reality the originating
system will now need to impose a checksum that is invalid at the start for it
to be correct at the end – breaking end to end check summing. This is a
problem.
Let’s look at what 8200 says:
o 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.
Now, in the case of no SRH – the DA address placed by the originating host – is
*NOT* the final DA – because of the manipulation in the middle.
The reality is that middleware boxes are (unfortunately) common – especially in
this part of the world – they are used by state and other entities for DPI and
traffic control etc – and they are used for IDS purposes etc – and breaking the
L4 checksum in flight with no way for these boxes to calculate the correct
checksum – will break existing deployments – that – is a problem and it needs
to be addressed. I would be quite fine if there was explicit text detailing
this that was explicitly approved by 6man as the originators of 8200 (and a
clear indication that this document updates 8200) – or alternatively a -BIS to
8200. Either way – if you break the checksum – this needs explanatory text and
it needs approval for 6man via a 6man Last call as far as I am concerned.
Thanks
Andrew
Internal All Employees
From: Antoine FRESSANCOURT <[email protected]>
Date: Tuesday, 6 February 2024 at 12:16
To: Andrew Alston - IETF <[email protected]>, Robert Raszuk
<[email protected]>, Ron Bonica <[email protected]>
Cc: [email protected] <[email protected]>
Subject: RE: [spring] draft-ietf-spring-srv6-srh-compression
Hello,
I tend to agree with Andrew that the fact that the verification of a L4
checksum by a middlebox breaks is a problem. But I think this is a huge problem
with the middleboxes, not with SRv6.
According to me, reading RFC 8200 gives rather clear guidelines with regards to
the computation of the L4 checksum. This checksum should be computed using the
destination address seen by the destination verifying the checksum. As L4
protocols are end to end protocols, the checksum verifier is the end point
destination of the packet, and not a middlebox on the path. If a middlebox
breaks the communication by looking at fields it should not look at, then the
problem is the intervention of the middlebox.
Best,
Antoine
From: spring <[email protected]> On Behalf Of Andrew Alston - IETF
Sent: lundi 5 février 2024 20:32
To: Robert Raszuk <[email protected]>; Ron Bonica <[email protected]>
Cc: [email protected]
Subject: Re: [spring] draft-ietf-spring-srv6-srh-compression
I call breaking any middleware that does checksum validation a problem - and a
big one
Andrew Alston
Internal All Employees
________________________________
From: Robert Raszuk <[email protected]<mailto:[email protected]>>
Sent: Monday, February 5, 2024 7:16:23 PM
To: Ron Bonica <[email protected]<mailto:[email protected]>>
Cc: Andrew Alston - IETF
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: Re: [spring] draft-ietf-spring-srv6-srh-compression
Hi Ron,
Is there a problem ?
If I read RFC8200 L4 checksum is computed by the packet originator and
validated by the packet's ultimate receiver.
In all SPRING work to the best of my knowledge the vast majority of packets are
only encapsulated by transit nodes.
Is there any formal mandate in any of the RFCs that an encapsulating node must
mangle the inner packet's L4 checksum ? I don't think so but stand open to get
my understanding corrected.
Cheers,
Robert
On Mon, Feb 5, 2024 at 5:04 PM Ron Bonica
<[email protected]<mailto:[email protected]>>
wrote:
Folks,
Has anyone proposed a solution to the L4 checksum problem that Andrew talks
about?
Ron
Juniper Business Use Only
________________________________
From: spring <[email protected]<mailto:[email protected]>> on
behalf of Andrew Alston - IETF
<[email protected]<mailto:[email protected]>>
Sent: Monday, February 5, 2024 5:21 AM
To: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: [spring] draft-ietf-spring-srv6-srh-compression
[External Email. Be cautious of content]
Hi All,
(In capacity as a contributor and wearing no other hats)
At this point I cannot support progression of this document until the issues
around the L4 Checksum have been resolved. It’s been clearly stated in other
emails on the list that in certain circumstances the behavior described in this
document break the L4 checksum as defined in RFC8200. This requires an update
to RFC8200 to fix it – and I’m not sure that spring can update 8200 absent the
consent of 6man, which I’m not sure has been asked for, nor am I sure that a
spring document can update something like 8200 in an area so fundamental as the
checksum without a -BIS, which would have to be done via 6man. The L4 checksum
issue though is real – and it cannot simply be ignored.
I also have deep concerns that the compression document creates something that
(in a similar way to SRv6) creates something that is completely non-conformant
with RFC4291. There are multiple references to this in draft-6man-sids, and
should draft-6man-sids become an RFC I would argue that it should probably be a
normative reference in this document – on the logic that this document relies
on similar RFC4291 violations that srv6 itself does (and for the record, just
because SRv6 itself violates RFC4291 as is clearly documented in
draft-6man-sids – does not make it acceptable to do so in yet another draft
without clear and unambiguously stating the deviations and ideally updating
RFC4291 to allow for said deviations)
I believe these two issues alone are sufficient that to pass this document
would create still further tensions about the relationship between SRv6 and
IPv6 and lead to confusion. As such – I believe these issues need to be
adequately dealt with – and the solutions to them need to be approved by 6man
as the working group that holds responsibility for ipv6 maintenance.
Thanks
Andrew Alston
Internal All Employees
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
