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
