Ben, thanks for your comment. Yes at the beginning we thought what you thought, we consider the solution as “Negotiate it up front (in IKEv2)”, however the challenge here is the MTU of the router on the forwarding path can be changed at any time (for example, the router changes the configuration for some reason, or changes the forwarding path for some reason).
If the MTU of any forwarding node on the forwarding path changes (even as to the whole forwarding path changes), a pre-negotiated MTU is probably not applicable. Therefore, we defined the solution is to discover MTU in-band via error responses. Brs From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Ben Schwartz Sent: Saturday, July 29, 2023 8:01 AM To: Daniel Migault <mglt.i...@gmail.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification +mailing list (oops) I think I understand the difficulty here. In IPv6, a "maximum reassembled ESP size" can be modeled as a next-hop MTU on the plaintext, but in IPv4 an enormous ESP could be decrypted and fragmented forward over a next hop with a reasonable MTU. If this kind of ESP size limit is allowed, I think the best architecture would be to negotiate it up front (in IKEv2) since it is a static property of the endpoints, rather than discovering it in-band via error responses. --Ben Schwartz ________________________________ From: Daniel Migault <mglt.i...@gmail.com<mailto:mglt.i...@gmail.com>> Sent: Friday, July 28, 2023 10:47 AM To: Ben Schwartz <bem...@meta.com<mailto:bem...@meta.com>> Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification I see the next link as being the network behind the egress security gateway in which case the paquet would be the clear text packet. In that case maybe we could expect a ICMP PTB being sent to the source. The scenario we have is the packet I see the next link as being the network behind the egress security gateway in which case the paquet would be the clear text packet. In that case maybe we could expect a ICMP PTB being sent to the source. The scenario we have is the packet being so big that decryption cannot be performed - for example once reassembled. The egress security gateway has an ESP packet that it cannot process. The normal way would be to send an ICMP PTB but that ICMP PTB does not contain sufficient information for the egress to address the issue. The IKE message could be seen as duplicating the ICMP PTB with additional guarantees. Yours, Daniel On Fri, Jul 28, 2023 at 1:33 AM Ben Schwartz <bem...@meta.com<mailto:bem...@meta.com>> wrote: I don't understand what it would mean for an ESP packet to be "too big to be decrypted". Do you mean that the decrypted payload is too big to deliver on the next link? --Ben Schwartz ________________________________ From: IPsec <ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org>> on behalf of Daniel Migault <mglt.i...@gmail.com<mailto:mglt.i...@gmail.com>> Sent: Thursday, July 27, 2023 9:32 PM To: IPsecME WG <ipsec@ietf.org<mailto:ipsec@ietf.org>> Subject: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification In yesterday's presentation of the -ikev2-mtu-dect draft, I was asked why do we have such a notification instead of using a standard ICMP PTB message encapsulated in ESP. I believe the confusion comes from me saying that the PTB message In yesterday's presentation of the -ikev2-mtu-dect draft, I was asked why do we have such a notification instead of using a standard ICMP PTB message encapsulated in ESP. I believe the confusion comes from me saying that the PTB message is sent AFTER the packet has been decrypted. This is not the case as the PTB is sent BECAUSE the encrypted packet is too big and so cannot be decrypted. In other words the packet that is too big is the ESP packet. If the packet is too big and cannot be decrypted a Packet Too Big Notification (PTB) that specifies the Link MTU (LMTU) of the router component of the egress node (on network N) as well as the effective MTU to receive (EMTU_R). Both are configuration parameters. An ICMP PTB message may also be sent by the egress node. Note that this ICMP may not contain even the SPI, and so is likely to not carry sufficient information to the ingress node, so any action be taken. Typically the ICMP message only carries the first 8 bytes start from IP header of the original packets. This is not sufficient when encapsulated as the 8 bytes will not contain the SPI and the egress gateway will not be able to identify the concerned SA and so the concerned flow. Yours, Daniel -- Daniel Migault Ericsson -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
