Hi Andrew, Any thoughts on the below?
Thanks, Francois On Feb 8, 2024 at 16:03:57, Francois Clad <fclad.i...@gmail.com> wrote: > Hi Andrew, > > Assuming that Nick is correct and that you are indeed referring to > middleboxes as defined in RFC 3234, can you describe the problem that a > network operator would face when deploying SRv6 with C-SID compression to > encapsulate the end-user traffic (i.e., encapsulate on ingress PE and > decapsulate on egress PE) traversing their network? > > Will those middleboxes inspect the L4 header of the encapsulated IP packet > (or Ethernet frame)? Given that they would compute the checksum using the > pseudo-header of the inner IP packet, the SRv6 encapsulation should not > cause any problem there, right? > > Thanks, > Francois > > > On Feb 7, 2024 at 01:00:28, Andrew Alston - IETF <andrew-i...@liquid.tech> > wrote: > >> Hi Nick, >> >> Speaking with no hats >> >> I’ve gotta unfortunately tread fairly carefully here - but yes - such >> systems exist. Systems to do passive abnormality checking on the network >> and analyzing packets and packet flows that do l4 checksum validation and a >> host of other things to look for traffic abnormalities across backbone >> systems etc and react/ alert accordingly. >> >> These systems do do layer 4 checksumming and a host of other things in >> their analysis - and would be pretty badly thrown off if all the checksums >> suddenly went to hell and it couldn’t calculate them. Unfortunately I’m >> simply not in a position where I can say more than that - suffice to say >> they exist and this would cause issues >> >> Andrew >> >> Andrew Alston >> >> Internal All Employees >> ------------------------------ >> *From:* Nick Buraglio <burag...@forwardingplane.net> >> *Sent:* Wednesday, February 7, 2024 2:32:22 AM >> *To:* Robert Raszuk <rob...@raszuk.net> >> *Cc:* Andrew Alston - IETF <andrew-i...@liquid.tech>; Antoine >> FRESSANCOURT <antoine.fressanco...@huawei.com>; Francois Clad < >> fclad.i...@gmail.com>; Nick Hilliard <n...@foobar.org>; Ron Bonica < >> rbon...@juniper.net>; spring@ietf.org <spring@ietf.org> >> *Subject:* Re: [spring] draft-ietf-spring-srv6-srh-compression >> >> Well, the reason I ask is because there are plausible use cases for >> running SRv6 on hosts to create TE paths across a WAN or to a DTN (data >> transfer node) and I have definitely seen large carrier grade middle boxes >> in the paths of WANs. >> Part of what my org does is to facilitate very large, performant data >> transfers across LFNs and I could see this being a potential issue, even >> though there have been great pains taken to remove middle boxes in the path >> of what we are doing (see: ScienceDMZ). >> What I have not seen is a middle box that does, as far as I know, L4 >> checksum checking, or that understands SRv6 and is doing so in concert with >> things like DPI. >> I’m not trying to debate that there may be an issue, more trying to >> understand the current landscape and what may be in use in the future. >> >> what I’ve seen is two fold: a complete ignorance of routing headers and a >> complete filter of them. >> >> >> On Tue, Feb 6, 2024 at 4:05 PM Robert Raszuk <rob...@raszuk.net> wrote: >> >> Hey Nick, >> >> All I could perhaps add to this thread here is that from my >> experience the "middleboxes" RFC3234 talks about are placed at the edges or >> peripherals of the core networks (example DMZs). In those parts of the >> network rarely anyone runs any form of SRv6 be it with or without SRH. >> >> So while in theory you could put an IDS/IPS in the middle of the 400G >> core transit in practice it is never the case. >> >> Kind regards, >> Robert >> >> >> >> On Tue, Feb 6, 2024 at 10:49 PM Nick Buraglio < >> burag...@forwardingplane.net> wrote: >> >> 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
