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

[Nick Hilliard <[e-mail]>]

Robert,

Usually (but not always) networks which deploy a strict edge + core 
architecture would avoid middleboxes in the core, but most networks are 
more heterogeneous than that, as Andrew pointed out further up this thread.

Nick

Robert Raszuk wrote on 06/02/2024 22:04:
> 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
>