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

[Francois Clad <[e-mail]>]

 Hi Andrew,

Any thoughts on the below?

Thanks,
Francois

On Feb 8, 2024 at 16:03:57, Francois Clad <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
>> *Sent:* Wednesday, February 7, 2024 2:32:22 AM
>> *To:* Robert Raszuk <[e-mail]>
>> *Cc:* Andrew Alston - IETF <[e-mail]>; Antoine
>> FRESSANCOURT <[e-mail]>; Francois Clad <
>> [e-mail]>; Nick Hilliard <[e-mail]>; Ron Bonica <
>> [e-mail]>; [e-mail] <[e-mail]>
>> *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 <[e-mail]> 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 <
>> [e-mail]> wrote:
>>
>> On Tue, Feb 6, 2024 at 1:58 PM Nick Hilliard <[e-mail]> 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=
>> [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://www.ietf.org/mailman/listinfo/spring
>> >>
>> >> _______________________________________________
>> >> spring mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/spring
>> >
>> >
>> >
>> > _______________________________________________
>> > spring mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/spring
>> >
>> >
>> > _______________________________________________
>> > spring mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/spring
>>
>>