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 <robert@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 <
> buraglio@forwardingplane.net> wrote:
>
>> On Tue, Feb 6, 2024 at 1:58 PM Nick Hilliard <nick@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.tech@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.com@dmarc.ietf.org>
>> >> Date: Tuesday, 6 February 2024 at 12:16
>> >> To: Andrew Alston - IETF <andrew-ietf@liquid.tech>, Robert Raszuk <
>> robert@raszuk.net>, Ron Bonica <rbonica@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-bounces@ietf.org> On Behalf Of Andrew Alston -
>> IETF
>> >> Sent: lundi 5 février 2024 20:32
>> >> To: Robert Raszuk <robert@raszuk.net>; Ron Bonica <rbonica@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 <robert@raszuk.net>
>> >> Sent: Monday, February 5, 2024 7:16:23 PM
>> >> To: Ron Bonica <rbonica@juniper.net>
>> >> Cc: Andrew Alston - IETF <andrew-ietf@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.net@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-bounces@ietf.org> on behalf of Andrew Alston -
>> IETF <andrew-ietf=40liquid.tech@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
>>
>