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<mailto:rob...@raszuk.net>> Sent: Monday, February 5, 2024 7:16:23 PM To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>> Cc: Andrew Alston - IETF <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>>; spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto: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<mailto: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<mailto:spring-boun...@ietf.org>> on behalf of Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org<mailto:40liquid.t...@dmarc.ietf.org>> Sent: Monday, February 5, 2024 5:21 AM To: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto: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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
