On Tue, Feb 6, 2024 at 1:58 PM Nick Hilliard <n...@foobar.org> wrote: > > Francois, > > Fairly sure Andrew was referring to middleboxes, as defined in rfc3234. > > In terms of what rfc8200 does or doesn't say, if srv6 is going to unearth > problems with the well-established operational practices of embedding > middleboxes deeply inside networks, then this will need to be addressed. > Protocols have to work, and 30 years of middleboxes aren't going to go away > any time soon.
Definitely agree with the middle box issue, middle boxes aren't going away and are fairly pervasive. As I asked previously, and Tal more eloquently requested, do we have examples we can reference for failure? Do we have a working example of a middle box that can verify a checksum with a SRH? That would imply that the middle box either participates in an SRv6 domain or ignores / passes the RH4. My testing of many core routing platforms has left me wanting in the "filtering RH4" department, and middle boxes tend to lag a handful of years behind carrier gear. > > Nick > > Francois Clad wrote on 06/02/2024 16:58: > > 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 > > > _______________________________________________ > 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
