Hi everyone,
Considering the various comments here is our understanding of the IKE PTB status. The IKE PTB, in our view, is largely motivated by enabling the egress interface to provide the EMTU_R to the ingress interface. This results from the discussion with Joe Touch who references the document in section 4.2.2.1 of draft-intarea-tunnels [1]. As there is a long history where tunnels have been established without this parameter, we may be able to live without that message, however we believe that it is better to have such a mechanism. Typically, with an IPsec tunnel, a packet that exceeds the EMTU_R (let’s say after reassembly), will not result in sending an ICMP PTB neither by the interface nor by the router. That packet will be discarded, and the ingress node will not be informed of it. In our mind the EMTU_R can result from a combination between a hardware configuration parameter, the egress interface and optionally the MTU of the egress router. We believe that the EMTU_R may change over time and that it should be provided when a packet exceeds that EMTU_R as opposed to being provided once for all during the IKE exchange. However, we agree that EMTU_R and MTU may be provided during the IKE exchange. So far, our position is that the IKE PTB should be specified. We also envisioned some additional advantages that the IKE PTB MAY provide. However, while these have been discussed, we want to make it clear that these other advantages are secondary. Firstly IKE PTB MAY be sent in conjunction of an ICMP PTB by the interface. The advantages of doing so are that ICMP is authenticated and clearly associated with the SA. More specifically, an ICMP PTB sent upon receiving an UDP/ESP packet does not carry the SPI. However, this advantage is only provided by the egress interface and so that mechanism cannot be used by any other node, and so cannot be used for PMTU discovery. Secondly, the IKE PTB MAY be sent together with the ICMP PTB sent by the router. We believe this improves the network latency and optimizes the use of the security gateway resources. In fact the ICMP PTB sent by the egress router is sent specifically to the sending source, and so one can expect the ICMP PTB being sent to every source. By sending the IKE PTB, the ICMP PTB would be sent by the ingress router. This prevents the large packet greater than the MTU to be encrypted and sent to the egress router for nothing. We believe this could be an interesting use case. Please let us know if you agree / disagree, so we can update and clarify the draft along these lines. We will also clarify the “too large to be decrypted”. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ On Sat, Aug 5, 2023 at 10:44 PM Daniel Migault <mglt.i...@gmail.com> wrote: > > > On Wed, Aug 2, 2023 at 11:28 AM Paul Wouters <p...@nohats.ca> wrote: > >> On Tue, 1 Aug 2023, Daniel Migault wrote: >> >> [The quoting got mangled in Daniel's message] >> >> > If an incoming Encrypted packet is larger than the Link MTU >> > >> > >> > How can than be? You mean you received an ESP or ESPinUDP that after >> decrypting was too large for the >> > link you need to send the decrypted packet on? That seems really odd. >> > >> > I was trying to mention the very basic use of ICMP PTB here. There is >> no decryption at that point, that is if an IP packet IP/ESP or >> > IP/UDP/ESP is larger than the link MTU, an ICMP PTB will be sent. >> >> But before decryption, when using tunnel mode, you wouldn't know which >> interface to send the packet to, so you don't know yet if it is too big >> or not. So that makes me understand this use case even less. >> >> > 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. >> > >> > What is this “too large to decrypt” scenario ? Can you give more >> details? >> > >> > The reassembled packet is larger than EMTU_R for example. >> >> EMTU_R you defined as "effective MTU to receive". As you received >> fragments that fit that mtu, why does it matter what the reassembled >> packet size is? It would only matter if you would (after successfull >> decryption), need to send the packet back over the same interface. >> >> We want to avoid fragmentation but fragmentation remains supported. > EMTU_R is sent as an information to the peer that the fragmented packet has > not been handled by the egress gateway. > > >> My problem is that between Daniel and Joel explanations, I still haven't >> managed to understand the actual problem, so I have a really hard time >> understanding the proposed fix and whether it really would solve >> something. >> >> I think this is normal as these are two unrelated use cases/concerns. > Joel was describing DSCP being used as a pseudo traffic selector. > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ > > >> As Joe Touch wrote in January: >> >> The abstract clearly states a goal that is not achievable (of >> avoiding >> reassembly). The best way to avoid the impact of mid-tunnel >> fragmentation >> is to use IPv4 as a tunnel header the way that IPv6 would be - >> with >> DF=1. However, even so, the egress always needs to handle >> reasssembly >> as long as there is even source fragmentation. >> >> I appreciate what you WANT to do - but again, it is not possible. >> You >> have two behaviors - either use inner fragmentation (which won’t >> work >> for transit traffic where IPv4 DF=1 or any IPv6) or reduce the >> tunnel MTU. >> >> But the tunnel MTU is defined by EMTU_R of the tunnel egress, not >> EMTU_S >> of the tunnel ingress. If you reduce the tunnel MTU, you’re just >> going >> to end up black-holing packets arriving at the tunnel ingress. >> >> Two important points: the tunnel ingress is NOT the one that >> should >> ever send PTB back; that’s the job of the router where/if that >> tunnel >> ingress resides; second, you cannot claim to get around an ICMP >> black >> hole situation by creating a new ICMP black hole situation. >> >> >> I am happy to understand why you think we do avoid reassembly. At least > on our side it solves our issue. > >> Paul >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
