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....@dmarc.ietf.org
<mailto:40huawei....@dmarc.ietf.org>>
*Date: *Tuesday, 6 February 2024 at 12:16
*To: *Andrew Alston - IETF <andrew-i...@liquid.tech>, Robert Raszuk
<rob...@raszuk.net <mailto:rob...@raszuk.net>>, Ron Bonica
<rbon...@juniper.net <mailto:rbon...@juniper.net>>
*Cc: *spring@ietf.org <mailto:spring@ietf.org> <spring@ietf.org
<mailto: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-boun...@ietf.org
<mailto:spring-boun...@ietf.org>> *On Behalf Of *Andrew Alston - IETF
*Sent:* lundi 5 février 2024 20:32
*To:* Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>>;
Ron Bonica <rbon...@juniper.net <mailto:rbon...@juniper.net>>
*Cc:* spring@ietf.org <mailto: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 <rob...@raszuk.net <mailto:rob...@raszuk.net>>
*Sent:* Monday, February 5, 2024 7:16:23 PM
*To:* Ron Bonica <rbon...@juniper.net <mailto:rbon...@juniper.net>>
*Cc:* Andrew Alston - IETF <andrew-i...@liquid.tech
<mailto:andrew-i...@liquid.tech>>; spring@ietf.org
<mailto:spring@ietf.org> <spring@ietf.org <mailto: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....@dmarc.ietf.org
<mailto:40juniper....@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-boun...@ietf.org
<mailto:spring-boun...@ietf.org>> on behalf of Andrew Alston -
IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org
<mailto:40liquid.t...@dmarc.ietf.org>>
*Sent:* Monday, February 5, 2024 5:21 AM
*To:* spring@ietf.org <mailto:spring@ietf.org> <spring@ietf.org
<mailto: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 <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
