An encapsulated ICMP ECHO would get a response from the router (not the interface) of the security gateway. I have not read carefully draft-colitti-ipsecme-esp-ping but this is potentially what we could use to discover that path upon which we could set DF=1. That said, if MTU changes, we need to receive a notification. I tend to think that extending colitti-ipsecme-esp-ping to other ICMP plus defining PLMTU could replace our IKE PTB.
On Mon, Jul 31, 2023 at 12:57 PM Ben Schwartz <[email protected]> wrote: > It seems to me that the statement "This packet is too big for me to > decrypt" is quite different from "This packet arrived fragmented". The > former can generally be negotiated in the handshake, whereas the latter is > a dynamic behavior of the underlying path. > > Monitoring the Path MTU is important, even when the path traverses an ICMP > blackhole. So while I don't see the value of the PTB extension, I can > understand the rationale for the LMAP extension. However, I would like to > see a bit more description of the whole system. How do I send path probes > to elicit these responses? Can I use ICMP ECHO inside the tunnel, or do we > need draft-colitti-ipsecme-esp-ping? If we have path probes, why not just > set DF=1 on the outer header for PMTUD? > > --Ben Schwartz > ------------------------------ > *From:* Daniel Migault <[email protected]> > *Sent:* Monday, July 31, 2023 12:10 PM > *To:* Ben Schwartz <[email protected]> > *Cc:* Harold Liu <[email protected]>; > [email protected] <[email protected]> > *Subject:* Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > Hi Ben, Please see my comments. On Mon, Jul 31, 2023 at 10: 47 AM Ben > Schwartz <bemasc@ meta. com> wrote: Hi Harold, It sounds like you're > describing a different problem. Daniel mentioned a concern about cases in > which "the encrypted > Hi Ben, > Please see my comments. > On Mon, Jul 31, 2023 at 10:47 AM Ben Schwartz <[email protected]> wrote: > > Hi Harold, > > It sounds like you're describing a different problem. Daniel mentioned a > concern about cases in which "the encrypted packet is too big and so cannot > be decrypted". > > We see the MTU indicating the size the packet the egress interface is able > to handle which includes the ability to reassemble and decrypt the packet. > In that sense, I see sending the EMTU_R as very similar to an ICMP PTB > except. I am wondering if you see any reasons for these issues to be > considered differently and how you think such distinction could help. > > That's quite different from an MTU limit on the forwarding path, which can > be dealt with using ordinary IP fragmentation and PMTUD. > > Fragmentation works, but costs too much resources and this draft is aiming > at reducing such operations. Our concern is with IPv4, where DF=1 leads to > a blackholing situation. PMTUD is extremely difficult as ICMP messages are > not received by the ingress gateway. > PLMTUD I-D.spiriyath-ipsecme-dynamic-ipsec-pmtu for ESP is another path, > but it would take a lot of effort. > > Yours, > Daniel > > > --Ben SchwartzI-D.spiriyath-ipsecme-dynamic-ipsec-pmtu > ------------------------------ > *From:* Harold Liu <[email protected]> > *Sent:* Sunday, July 30, 2023 9:28 PM > *To:* Ben Schwartz <[email protected]>; Daniel Migault <[email protected]> > *Cc:* [email protected] <[email protected]> > *Subject:* RE: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification > > 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 > > 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 <[email protected]> *On Behalf Of *Ben Schwartz > *Sent:* Saturday, July 29, 2023 8:01 AM > *To:* Daniel Migault <[email protected]> > *Cc:* [email protected] > *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 <[email protected]> > *Sent:* Friday, July 28, 2023 10:47 AM > *To:* Ben Schwartz <[email protected]> > *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 <[email protected]> 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 <[email protected]> on behalf of Daniel Migault < > [email protected]> > *Sent:* Thursday, July 27, 2023 9:32 PM > *To:* IPsecME WG <[email protected]> > *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 > > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
