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<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
