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
<[email protected] <mailto:[email protected]>>
wrote:
On Tue, Feb 6, 2024 at 1:58 PM Nick Hilliard <[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>>
>> Date: Tuesday, 6 February 2024 at 12:16
>> To: Andrew Alston - IETF <[email protected]>, Robert
Raszuk <[email protected] <mailto:[email protected]>>, Ron Bonica
<[email protected] <mailto:[email protected]>>
>> Cc: [email protected] <mailto:[email protected]> <[email protected]
<mailto:[email protected]>>
>> 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 <[email protected]
<mailto:[email protected]>> On Behalf Of Andrew Alston - IETF
>> Sent: lundi 5 février 2024 20:32
>> To: Robert Raszuk <[email protected]
<mailto:[email protected]>>; Ron Bonica <[email protected]
<mailto:[email protected]>>
>> Cc: [email protected] <mailto:[email protected]>
>> 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 <[email protected] <mailto:[email protected]>>
>> Sent: Monday, February 5, 2024 7:16:23 PM
>> To: Ron Bonica <[email protected] <mailto:[email protected]>>
>> Cc: Andrew Alston - IETF <[email protected]>;
[email protected] <mailto:[email protected]> <[email protected]
<mailto:[email protected]>>
>> 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
<[email protected]
<mailto:[email protected]>> wrote:
>>
>> Folks,
>>
>>
>>
>> Has anyone proposed a solution to the L4 checksum problem that
Andrew talks about?
>>
>>
>>
>> Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>> ________________________________
>>
>> From: spring <[email protected]
<mailto:[email protected]>> on behalf of Andrew Alston -
IETF <[email protected]
<mailto:[email protected]>>
>> Sent: Monday, February 5, 2024 5:21 AM
>> To: [email protected] <mailto:[email protected]> <[email protected]
<mailto:[email protected]>>
>> 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
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/spring
>>
>> _______________________________________________
>> spring mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/spring
>
>
>
> _______________________________________________
> spring mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/spring
>
>
> _______________________________________________
> spring mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
