It can be a good thing, in terms of deterring "man-in-the-middle attack." :-)
Miya On Wed, Feb 7, 2024 at 10:45 AM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > Folks, > > Someone raised the same objection with regard to the CRH Draft > <https://datatracker.ietf.org/doc/html/draft-ietf-6man-comp-rtg-hdr-03>. > Since there iss no easy solution to the problem, the authors simply > acknowledged the issue in Section 7 > <https://www.ietf.org/archive/id/draft-ietf-6man-comp-rtg-hdr-03.html#name-destination-address-transpa> > of > the draft. So, operators are warned. If you have middleboxes that verify L4 > checksums, don't deploy this technology. > > You might want to add a similar section in your draft. > > Ron > > > > Juniper Business Use Only > ------------------------------ > *From:* Tal Mizrahi <tal.mizrahi....@gmail.com> > *Sent:* Tuesday, February 6, 2024 9:46 AM > *To:* Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org> > *Cc:* Antoine FRESSANCOURT <antoine.fressancourt= > 40huawei....@dmarc.ietf.org>; Robert Raszuk <rob...@raszuk.net>; Ron > Bonica <rbon...@juniper.net>; spring@ietf.org <spring@ietf.org> > *Subject:* Re: [spring] draft-ietf-spring-srv6-srh-compression > > [External Email. Be cautious of content] > > > Dear Andrew, > > A couple of questions regarding the middlebox use case. > > 1. I am curious to know whether there are existing middleboxes that > can verify the L4 checksum for packets with an SRH. > 2. Can a middlebox verify the L4 checksum of a packet with an SRH *in > compliance with RFC 8200*? > RFC 8200 defines the pseudo-header "At the originating node" and "at > the recipient(s)", but does not say anything about middleware. Is it > implicitly assumed that the middleware is an "originating node"? > > Cheers, > Tal. > > On Tue, Feb 6, 2024 at 12:16 PM 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!EP3H1Kg-F8iNFIm1BpYH1ioC5lNtcd6S3XisWWZon80eZtRk_HyIophSpxWJ3vs0xKMM5bzRHw06xBX92ckK4KYwdw$ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!EP3H1Kg-F8iNFIm1BpYH1ioC5lNtcd6S3XisWWZon80eZtRk_HyIophSpxWJ3vs0xKMM5bzRHw06xBX92ckK4KYwdw$ > _______________________________________________ > 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
