Re: [spring] draft-ietf-spring-srv6-srh-compression

[Miya Kohno <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]>
> *Sent:* Tuesday, February 6, 2024 9:46 AM
> *To:* Andrew Alston - IETF <andrew-ietf=[e-mail]>
> *Cc:* Antoine FRESSANCOURT <antoine.fressancourt=
> [e-mail]>; Robert Raszuk <[e-mail]>; Ron
> Bonica <[e-mail]>; [e-mail] <[e-mail]>
> *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=[e-mail]> 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=
> [e-mail]>
> > Date: Tuesday, 6 February 2024 at 12:16
> > To: Andrew Alston - IETF <[e-mail]>, Robert Raszuk <
> [e-mail]>, Ron Bonica <[e-mail]>
> > Cc: [e-mail] <[e-mail]>
> > 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 <[e-mail]> On Behalf Of Andrew Alston - IETF
> > Sent: lundi 5 février 2024 20:32
> > To: Robert Raszuk <[e-mail]>; Ron Bonica <[e-mail]>
> > Cc: [e-mail]
> > 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 <[e-mail]>
> > Sent: Monday, February 5, 2024 7:16:23 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: Andrew Alston - IETF <[e-mail]>; [e-mail] <
> [e-mail]>
> > 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=
> [e-mail]> wrote:
> >
> > Folks,
> >
> >
> >
> > Has anyone proposed a solution to the L4 checksum problem that Andrew
> talks about?
> >
> >
> >
> >                                           Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > ________________________________
> >
> > From: spring <[e-mail]> on behalf of Andrew Alston -
> IETF <andrew-ietf=[e-mail]>
> > Sent: Monday, February 5, 2024 5:21 AM
> > To: [e-mail] <[e-mail]>
> > 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
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!EP3H1Kg-F8iNFIm1BpYH1ioC5lNtcd6S3XisWWZon80eZtRk_HyIophSpxWJ3vs0xKMM5bzRHw06xBX92ckK4KYwdw$
> >
> > _______________________________________________
> > spring mailing list
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!EP3H1Kg-F8iNFIm1BpYH1ioC5lNtcd6S3XisWWZon80eZtRk_HyIophSpxWJ3vs0xKMM5bzRHw06xBX92ckK4KYwdw$
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>