Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

[Daniel Migault <[e-mail]>]

On Wed, Aug 2, 2023 at 1:02 AM Christian Hopps <[e-mail]> wrote:

>
> "Panwei (William)" <william.panwei=[e-mail]> writes:
>
> > Hi Daniel,
> >
> >
> >
> > Thanks for your clarification, I think I may have better
> > understanding of your problem statement. I try to give an example
> > below, please correct me if I’m wrong.
> >
> > First, let’s assume the encryption/decryption capability of ingress
> > node is 15000 bytes and the capability of egress node is 5000 bytes.
> > And, in one case, the original (inner) packet which needs to be
> > encrypted by the ingress node is 9000 bytes.
> >
> > The ingress node encrypts this packet and adds the IPsec
> > encapsulation, and this IPsec-processed packet is also larger than
> > the Link MTU. The ingress node fragments this IPsec-processed packet
> > and sends all the fragments to the egress node.
>
> This should not happen. The ingress node should first fragment the inner
> IP packet so that it fits in the tunnel (i.e., so that the ESP packets it
> creates do not violate it's own MTU).
>

It is correct that inner packets are not expected to exceed the tunnel MTU.
But in your case if the tunnel MTU is 15000 and teh packet is 9000 bytes,
your understanding seems correct.

According to draft-ietf-intarea-tunnels the ingress node compares the inner
packet with tunMAP - that is the largest packet that does not result in
fragmentation. If the packet exceeds such size, the ingress gateway
encapsulates the packet and fragments the big packet.

While the numbers are not realistic, if the tunnel MTU is 15000 and you
send a 9000 byte packet, the ingress   gateway will send 500 bytes
fragments. These fragments will be reassembled by the egress before
performing the decryption. It needs to be able to handle a 9000 byte
packet.


> > The egress node reassembles the packet and realizes the encrypted
> > packet exceeds its decryption capability, so it will drop the packet
> > and notify the ingress node.
>
> Yes, that is correct.

> > I don’t know whether this case is a real problem. And, I also don’t
> > know whether the ICMP PTB can solve the problem. If not, then I agree
> > the IKE PTB defined by this draft is a way to forward.
>
> I was thinking this "size exceeds decryption capability" is some sort of
> miscommunication. The draft talks about "packet too big and can't be
> decrypted", but is it really trying to say "the outer ESP packet didn't
> arrive b/c it was TOO BIG."?


> Otherwise is the text actually talking about a real limitation of some
> IPsec implementations -- that they can only decrypt up to a certain number
> of bytes per packet? It seems outrageous. :)
>
> I see. In my mind it cannot be decrypted as I imagine ipsec does not have
the full packet - basically it happens before the decapsulation. But I see
your point. I will clarify this.


> Thanks,
> Chris.
>
>
> > Besides that, I found many acronyms are used in this draft. I think
> > simplifying them may be better for understanding.
> >
> > For example, LMTU (Link MTU) and LMAP (Link Maximum Atomic Packet)
> > are both used, but I feel they are the same thing.
> >
> > TLP (Tunnel Link Packet) and LTP (no definition) are both used, and I
> > think LTP is misspelled. In some cases, “IPsec encapsulated TTP” is
> > used, and I think it also means TLP.
> >
> >
> >
> > Regards & Thanks!
> >
> > Wei Pan (潘伟)
> >
> >
> >
> > From: IPsec [mailto:[e-mail]] On Behalf Of Daniel
> > Migault
> > Sent: Wednesday, August 2, 2023 12:56 AM
> > To: Ben Schwartz <[e-mail]>
> > Cc: Harold Liu <harold.liu=[e-mail]>;
> > [e-mail]
> > Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
> >
> >
> >
> > Hi Ben,
> >
> > Just trying to position our understanding of  the position between the
> ICMP PTB and the IKE PTB.
> >
> > If an incoming Encrypted packet is larger than the Link MTU, an ICMP PTB
> is sent, otherwise the packet is accepted. If fragments are received, a
> reassembly operation happens and the packet may be too large to be built or
> decrypted. I am unaware of any ICMP signaling between the gateway that
> could carry this information. As far as I understand, ICMP PTB is not
> issued for a reassembled packet as long as each of the fragments are below
> the MTU. This is the reason we send the EMTU_R which designates the maximum
> size the egress gateway can handle.
> >
> > EMTU_R could be a configuration parameter that would not change, but
> that value also considers the MTU of the router part which can be changed.
> >
> > As soon as it passes the interface, as I understand it, an ICMP PTB will
> be sent to the Source and not the gateway. As I understand it, EMTU_R
> defines the maximum payload the Link network is able to handle. In our
> case, the payload is the encrypted ESP packet that may have been
> reassembled. The packet is passed to the decryption.  Once decrypted, the
> clear text packet is passed to the router of the node. The router may send
> an ICMP PTB, which will be sent to the Source or treat that packet. I see
> EMTU_R as reflecting the node of the router with Tunnel MTU = EMTU_R - ESP
> overhead
> >
> > Considering a ping encapsulated in esp - we may discover the MTU as well
> as the EMTU_R by fragmenting unless we meet EMTU_R.
> >
> > Note also that since we want to avoid fragmentation having a discovery
> mechanism that relies on fragmentation may not be the best idea.
> >
> > Yours,
> >
> > Daniel
> >
> >
> >
> > On Mon, Jul 31, 2023 at 1:22 PM Daniel Migault <[e-mail]>
> > wrote:
> >
> >     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 <[e-mail]>
> >     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 <[e-mail]>
> >         Sent: Monday, July 31, 2023 12:10 PM
> >         To: Ben Schwartz <[e-mail]>
> >         Cc: Harold Liu <harold.liu=[e-mail]>;
> >         [e-mail] <[e-mail]>
> >         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 <
> >         [e-mail]> 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 <harold.liu=
> >             [e-mail]>
> >             Sent: Sunday, July 30, 2023 9:28 PM
> >             To: Ben Schwartz <[e-mail]>; Daniel Migault <
> >             [e-mail]>
> >             Cc: [e-mail] <[e-mail]>
> >             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 <[e-mail]> On Behalf Of Ben
> >             Schwartz
> >             Sent: Saturday, July 29, 2023 8:01 AM
> >             To: Daniel Migault <[e-mail]>
> >             Cc: [e-mail]
> >             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 <[e-mail]>
> >             Sent: Friday, July 28, 2023 10:47 AM
> >             To: Ben Schwartz <[e-mail]>
> >             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 <
> >             [e-mail]> 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 <[e-mail]> on behalf of
> >                 Daniel Migault <[e-mail]>
> >                 Sent: Thursday, July 27, 2023 9:32 PM
> >                 To: IPsecME WG <[e-mail]>
> >                 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
>
>

-- 
Daniel Migault
Ericsson