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

[Andrew Alston - IETF <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>> wrote:
On Tue, Feb 6, 2024 at 1:58 PM Nick Hilliard <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
>> Date: Tuesday, 6 February 2024 at 12:16
>> To: Andrew Alston - IETF <[e-mail]>, Robert Raszuk <[e-mail]<mailto:[e-mail]>>, Ron Bonica <[e-mail]<mailto:[e-mail]>>
>> Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Andrew Alston - IETF
>> Sent: lundi 5 février 2024 20:32
>> To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Ron Bonica <[e-mail]<mailto:[e-mail]>>
>> Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>
>> Sent: Monday, February 5, 2024 7:16:23 PM
>> To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
>> Cc: Andrew Alston - IETF <[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> on behalf of Andrew Alston - IETF <andrew-ietf=[e-mail]<mailto:[e-mail]>>
>> Sent: Monday, February 5, 2024 5:21 AM
>> To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/spring
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/spring
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spring
>
>
> _______________________________________________
> spring mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spring