Hi Andrew, The L4 checksum issue that you have brought up is from the point of view of a “middleware” node. Is my understanding correct? This is not from either the source or destination node point of view which is covered by section 8.1 of RFC 8200.
Can you please describe this “middleware” and perhaps point to its IETF specification? Thanks, Francois On Feb 6, 2024 at 11:16:12, Andrew Alston - IETF <andrew-ietf= 40liquid.t...@dmarc.ietf.org> wrote: > 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 > <antoine.fressancourt=40huawei....@dmarc.ietf.org> > *Date: *Tuesday, 6 February 2024 at 12:16 > *To: *Andrew Alston - IETF <andrew-i...@liquid.tech>, Robert Raszuk < > rob...@raszuk.net>, Ron Bonica <rbon...@juniper.net> > *Cc: *spring@ietf.org <spring@ietf.org> > *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 <spring-boun...@ietf.org> *On Behalf Of *Andrew Alston - > IETF > *Sent:* lundi 5 février 2024 20:32 > *To:* Robert Raszuk <rob...@raszuk.net>; Ron Bonica <rbon...@juniper.net> > *Cc:* spring@ietf.org > *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 <rob...@raszuk.net> > *Sent:* Monday, February 5, 2024 7:16:23 PM > *To:* Ron Bonica <rbon...@juniper.net> > *Cc:* Andrew Alston - IETF <andrew-i...@liquid.tech>; spring@ietf.org < > spring@ietf.org> > *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 <rbonica= > 40juniper....@dmarc.ietf.org> wrote: > > Folks, > > > > Has anyone proposed a solution to the L4 checksum problem that Andrew > talks about? > > > > Ron > > > > Juniper Business Use Only > ------------------------------ > > *From:* spring <spring-boun...@ietf.org> on behalf of Andrew Alston - > IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org> > *Sent:* Monday, February 5, 2024 5:21 AM > *To:* spring@ietf.org <spring@ietf.org> > *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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
