Chris,
The -17 version indeed addresses one of the 4 DISCUSS points, namely the hop
limit vs. TTL. Thank you for this.
I am far from being convinced that the added text about ICMP handling is rock
solid though. While I cannot point a specific issue, I fear that aggregating
and fragmenting inner packets and receiving one ICMP on the outer packet is not
so trivial and some actual guidance based on actual testing would be welcome.
This is 'unknown territory' AFAIK (no other aggr/frag tunnels over IP were
specified/deployed before) and for a 'standards track' I-D, we need more
guidance.
The DISCUSS on the next header still holds of course. As I suggested, either
update RFC 4303/8200 or request an IP protocol number.
Regards
-éric
On 24/08/2022, 18:49, "iesg on behalf of Christian Hopps"
<iesg-boun...@ietf.org on behalf of cho...@chopps.org> wrote:
Éric Vyncke via Datatracker <nore...@ietf.org> writes:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> ## DISCUSS
>
> ### Section 2.2.6
>
> Please also mention hop-limit and RFC 8200.
>
> ### Absence of ICMP considerations
>
> Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As
several
> unprotected packets can be bundled together, some guidance to the
implementers
> will be welcome.
The section has been modified to address these concerns:
*** IPv4 Time-To-Live (TTL), IPv6 Hop Limit, and Tunnel errors
[[RFC4301]] specifies how to modify the inner packet IPv4 TTL [[RFC0791]]
or
IPv6 Hop Limit [[RFC8200]].
Any errors (e.g., ICMP errors) are handled the same as with
non-AGGFRAG IPsec tunnels. This applies to both the outer traffic as
well as the inner traffic prior to it entering the tunnel, see
[[RFC4301]].
I believe this should cover the rest of the items left in this DISCUSS
ballot.
Thanks,
Chris.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
