Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters writes: > On Mon, 7 Aug 2023, Tero Kivinen wrote: > > > Of course the optimal solution would be the original sender to not > > send 2000 byte packets, but instead fragment the packet already > > himself to 1300 bytes and 700 bytes, but that would require changes to > > the application and might not be that easy to do... > > And you think all these VPN gateways kernel stacks handling and tracking > and communicating upstrean to IKE to relay the message will be easier? Of course all proper VPN gateway products do that. They already do similar things when making sure ICMP error messages are processed correctly and end in correct tunnel, and that ICMP error messages for tunneled packets are processed so that they will trigger relevant ICMP messages sent to the proper hosts at correct time, and that fragment processing is done correctly etc. All of those are described in the RFC4301, and proper gateways implement them... And then there is linux :-) > I think people will just put mtu=1300 in their VPN config, use this new > notify and now we have yet another uncontrolled, unfixable hardcoded > packet size that will never go away again. And then there is linux :-) > The problem really is "create a 2000 byte packet and expect it to go > over the internet". Don't do that. If I remember right, at least NFS over udp does that (or it might use 8k packets), if I remember correctly... Nobody should be running NFS over udp over internet anyways, but it can happen over VPN links... Of course if you use IPv6 you do not have fragment in the middle issue, but even then you might have IPv6 packets inside the IPv4 ESP tunnel and end up in similar issues. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Mon, 7 Aug 2023, Tero Kivinen wrote: Of course the optimal solution would be the original sender to not send 2000 byte packets, but instead fragment the packet already himself to 1300 bytes and 700 bytes, but that would require changes to the application and might not be that easy to do... And you think all these VPN gateways kernel stacks handling and tracking and communicating upstrean to IKE to relay the message will be easier? I think people will just put mtu=1300 in their VPN config, use this new notify and now we have yet another uncontrolled, unfixable hardcoded packet size that will never go away again. The problem really is "create a 2000 byte packet and expect it to go over the internet". Don't do that. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters writes: > > You can't do that if DF=1, or IPv6. > > You can form big ESP packets and then fragment them, even with IPv6. > > DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant > > cope with fragments. > > Why does any of this even matter? The applications should use > PLPMTUD / DPLPMTUD ? That is fine if application can adjust the packet size... Lets say someone runs application protocol that sends 2000 byte UDP packets between the hosts. When those 2000 byte packets are sent over the first hop the system might be using setup where the MTU is over 2000 so they are sent as one packet. Then it reaches the normal ethernet with 1500 byte MTU, and the that 2000 byte packet gets fragmented to 1500 and 500 byte fragments. Next it arrives to the VPN gateway. VPN gateway will take the 1500 byte fragment and realize that after adding ESP header it does not fit to the 1500 byte MTU anymore, thus it fragments the packet BEFORE encryption to two packets, one for 1400 bytes and another for 100 bytes. Then it encrypts the 1400 byte packet, adds an ESP header and sends it out. Now it crosses the internet and somewhere there some router in the middle is having MTU that is 1400 bytes, and as the packet does not have DF bit set, that router fragments the ESP packet again to 1300 byte packet and 100 + ESP overhead byte long packet. The 2nd fragment of the origina packet was only 100 bytes, so it passes without issues The 2nd fragment of the original packet (500 bytes) is now 3rd fragment and is processed by the VPN gateway and it fits the MTU, i.e., VPN geteway encrypts it and adds an ESP header and sends it out. This packet will go through the network without any extra fragmentation. So now there is 4 packets to be received by the VPN gateway, an 1st fragment of the orignal packet which consist of ESP packet fragmented in two pieces, one 1300 bytes, and another ~140 bytes, and two ESP packes containing 2nd and 3rd fragments of the original packets, with sizess of 100 bytes, and 500 bytes. Now the receiving VPN gateway will see that it is getting fragmented ESP packets, and it needs to do reassembly before it can decrypt that fragmented ESP packet. If the sender VPN gateway would have know that someone will fragment his 1400 byte ESP packet he could have used split the original 1500 byte fragment differently and reduced the extra work for everybody. So if the receiving VPN gateway will send this LMAP notify to the sender VPN gateway saying that it is seeing someone in the network doing framentation on the ESP packets and the biggest packet it is seeing is 1300 bytes, then the sending VPN could simply use that information when it is fragmenting the packets before encrypting them. I.e., when it next time gets 1500 byte fragment it will not fragment it to refragment it to 1400 + 100 byte fragments, but instead use 1300 + 200, and after that the in the future the receving VPN gateway will not receive fragmented ESP packets. There final destination will still receive fragments, but instead of receiving them having sizes of 1400 + 100 + 500, it will receive them having sizes of 1300 + 200 + 500. If the sender VPN would use DF=1 for outgoing packets it would also get the same information from the network, but as the draft says you can't really trust getting those ICMP packet too big notifications through the network for the sender VPN gateway. And if you do not get those ICMP messages, then packets will get silenty dropped. Of course the optimal solution would be the original sender to not send 2000 byte packets, but instead fragment the packet already himself to 1300 bytes and 700 bytes, but that would require changes to the application and might not be that easy to do... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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 wrote: > > > On Wed, Aug 2, 2023 at 11:28 AM Paul Wouters 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
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 11:28 AM Paul Wouters 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Michael Richardson writes: [[PGP Signed Part:Signature made by expired key 808B70FBDDD0DD65 Michael Richardson ]] Paul Wouters wrote: >> > Or use IPTFS and set your own max packet size sufficiently low? >> >> I think that this is the killer app for IPTFS. >> > But of course this means either IPTFS should be able to auto-tune this, > or else we end up with hardcoded configs that might stop working or > cause future problems. I think that the ESPping mechanism is the right way to do "PLPMTUD" for IPTFS. (for the outer MTU) This is only the case for running IPTFS in the "secure mode" (i.e., sending at fixed intervals); however, we did put a bit in the congestion control header specifically to support PLPMTUD -- the P-bit: https://datatracker.ietf.org/doc/html/rfc9347#section-6.1.2 :) For demand sent IPTFS, something like and ESPping would probably be the way to go. Thanks, Chris. >> > I'm not convinced doing this between IPsec peers will solve any real >> > use cases. >> >> I am also skeptical, but I don't object to the work getting >> standardized. >> >> In particular, for networks where there are MTU constraints on the far >> side of the far gateway, telling the sending gateway about the MTU has >> a far higher chance of working than anything else. The sending >> gateway probably can send PTB ICMPs with better results. > There would need to be dynamic updating, kernel <-> userland > communications, etc. Just hardcoding this in an ikev2 configuration > would be pretty bad. yeah, I don't know exactly how to do the userland communication. How specific does it need to be is my question? How express that. Looking at mtu-dect, I'm unclear how the LMAP and and PTB describe the flow which has the MTU concern. It's mostly clear when it appears along with TSx that it applies to that traffic, but not for the other notifications. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Thu, Aug 3, 2023 at 9:12 AM Michael Richardson wrote: > > Paul Wouters wrote: > >> > Or use IPTFS and set your own max packet size sufficiently low? > >> > >> I think that this is the killer app for IPTFS. > >> > > > But of course this means either IPTFS should be able to auto-tune > this, > > or else we end up with hardcoded configs that might stop working or > > cause future problems. > > I think that the ESPping mechanism is the right way to do "PLPMTUD" for > IPTFS. > (for the outer MTU) > I also think so. > > >> > I'm not convinced doing this between IPsec peers will solve any > real > >> > use cases. > >> > >> I am also skeptical, but I don't object to the work getting > >> standardized. > >> > >> In particular, for networks where there are MTU constraints on the > far > >> side of the far gateway, telling the sending gateway about the MTU > has > >> a far higher chance of working than anything else. The sending > >> gateway probably can send PTB ICMPs with better results. > > > There would need to be dynamic updating, kernel <-> userland > > communications, etc. Just hardcoding this in an ikev2 configuration > > would be pretty bad. > > yeah, I don't know exactly how to do the userland communication. > How specific does it need to be is my question? How express that. > Looking at mtu-dect, I'm unclear how the LMAP and and PTB describe the flow > which has the MTU concern. It's mostly clear when it appears along with > TSx > that it applies to that traffic, but not for the other notifications. > > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters wrote: >> > Or use IPTFS and set your own max packet size sufficiently low? >> >> I think that this is the killer app for IPTFS. >> > But of course this means either IPTFS should be able to auto-tune this, > or else we end up with hardcoded configs that might stop working or > cause future problems. I think that the ESPping mechanism is the right way to do "PLPMTUD" for IPTFS. (for the outer MTU) >> > I'm not convinced doing this between IPsec peers will solve any real >> > use cases. >> >> I am also skeptical, but I don't object to the work getting >> standardized. >> >> In particular, for networks where there are MTU constraints on the far >> side of the far gateway, telling the sending gateway about the MTU has >> a far higher chance of working than anything else. The sending >> gateway probably can send PTB ICMPs with better results. > There would need to be dynamic updating, kernel <-> userland > communications, etc. Just hardcoding this in an ikev2 configuration > would be pretty bad. yeah, I don't know exactly how to do the userland communication. How specific does it need to be is my question? How express that. Looking at mtu-dect, I'm unclear how the LMAP and and PTB describe the flow which has the MTU concern. It's mostly clear when it appears along with TSx that it applies to that traffic, but not for the other notifications. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Christian Hopps wrote: > You're confusing inner and outer traffic here. When your egress > endpoint decaps the tunnel traffic, and then that traffic won't fit on > it's egress red link on your egress endpoint is going to send an ICMP > too big message back to the ingress router *inside the tunnel*. This > has nothing to do with the routers that carry the tunnel traffic. Assuming that this ICMP "fits" inside the tunnel. For bog-standard site to site VPNs, that mostly means that the source IP of the ICMP has to be the red link's IP. That's hard to get right, and Linux certainly does it wrong in my experience, using the outside IP. For a gateway that is linking two subnets, which are NOT directly connected, then it's even harder to get that ICMP right. This is where I think some other signal would be better. >> We do have mid tunnel fragmentation (with IPv4 of course). DF=0 is >> also preferred over dropping packets which results in a blackholing >> situation. > Can I ask, who is providing this mid-tunnel fragmentation service for > you? Your upstream provider, or a DFZ transit network like AT? I'm > curious b/c it's surprising that anyone is providing this service > anymore given it's an attack vector on their network. :) Yeah, but it still happens in IPv4. PPPoE makes it happen; the only way that it works with the bazillion banks that have ICMP turned off (because cisco pix default configuration of 20 years ago) is because IPv4 home routers fix the MSS. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 9:17 PM Michael Richardson wrote: > > Paul Wouters wrote: > >> Christian Hopps wrote: >> 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). > >> > >> You can't do that if DF=1, or IPv6. You can form big ESP packets > and > >> then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is > >> good, until there is a firewall that cant cope with fragments. > > > Why does any of this even matter? The applications should use > PLPMTUD / > > DPLPMTUD ? > > 1) For TCP things. We also have RFC9268 now. > Neat. I didn't know about that one. I guess we might get it for UDP too then if we get draft-ietf-tsvwg-udp-options :) > 2) how can we get it turned on by default? I tried to make this case to >Linux distros and kernel people, but there is a lack of evidence that >it is safe, and the people who might have the evidence (at scale) >don't want to do it. > > 3) the gateways really have no idea if PLPMTUD is being done, and sometimes >it's better to just make things work. > > > Sprinkling bits to try to communicate with hops in between hasn't > > worked for decades. > > Agreed. PMTUD is a fail. > > > Or use IPTFS and set your own max packet size sufficiently low? > > I think that this is the killer app for IPTFS. > But of course this means either IPTFS should be able to auto-tune this, or else we end up with hardcoded configs that might stop working or cause future problems. > > I'm not convinced doing this between IPsec peers will solve any real > > use cases. > > I am also skeptical, but I don't object to the work getting standardized. > > In particular, for networks where there are MTU constraints on the far side > of the far gateway, telling the sending gateway about the MTU has a far > higher > chance of working than anything else. The sending gateway probably can > send > PTB ICMPs with better results. > There would need to be dynamic updating, kernel <-> userland communications, etc. Just hardcoding this in an ikev2 configuration would be pretty bad. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 1:02 AM Christian Hopps wrote: > > "Panwei (William)" 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:ipsec-boun...@ietf.org] On Behalf Of Daniel > > Migault > > Sent: Wednesday, August 2, 2023 12:56 AM > > To: Ben Schwartz > > Cc: Harold Liu ; > > ipsec@ietf.org > > 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 interfac
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, Aug 2, 2023 at 9:17 PM Michael Richardson wrote: > > Paul Wouters wrote: > >> Christian Hopps wrote: >> 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). > >> > >> You can't do that if DF=1, or IPv6. You can form big ESP packets > and > >> then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is > >> good, until there is a firewall that cant cope with fragments. > > > Why does any of this even matter? The applications should use > PLPMTUD / > > DPLPMTUD ? > > 1) For TCP things. We also have RFC9268 now. > > 2) how can we get it turned on by default? I tried to make this case to >Linux distros and kernel people, but there is a lack of evidence that >it is safe, and the people who might have the evidence (at scale) >don't want to do it. > > 3) the gateways really have no idea if PLPMTUD is being done, and sometimes >it's better to just make things work. > > > Sprinkling bits to try to communicate with hops in between hasn't > > worked for decades. > > Agreed. PMTUD is a fail. > > > Or use IPTFS and set your own max packet size sufficiently low? > > I think that this is the killer app for IPTFS. > > > I'm not convinced doing this between IPsec peers will solve any real > > use cases. > > I am also skeptical, but I don't object to the work getting standardized. > > In particular, for networks where there are MTU constraints on the far side > of the far gateway, telling the sending gateway about the MTU has a far > higher > chance of working than anything else. The sending gateway probably can > send > PTB ICMPs with better results. > Just note that IKE PTB is really not the core of the draft and the LMAP is the main notification, IKE PTB is mentioned for completeness. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
t; On Mon, Jul 31, 2023 at 12:57 PM Ben Schwartz > > 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 > > Sent: Monday, July 31, 2023 12:10 PM > > To: Ben Schwartz > > Cc: Harold Liu ; > > ipsec@ietf.org > > 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 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 < > > bem...@meta.com> 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 > 40ericsson@dmarc.ietf.org> > > Sent: Sunday, July 30, 2023 9:28 PM > > To: Ben Schwartz ; Daniel Migault < > > mglt.i...@gmail.com> > > Cc: ipsec@ietf.org > > 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 M
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters wrote: >> Christian Hopps wrote: >> 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). >> >> You can't do that if DF=1, or IPv6. You can form big ESP packets and >> then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is >> good, until there is a firewall that cant cope with fragments. > Why does any of this even matter? The applications should use PLPMTUD / > DPLPMTUD ? 1) For TCP things. We also have RFC9268 now. 2) how can we get it turned on by default? I tried to make this case to Linux distros and kernel people, but there is a lack of evidence that it is safe, and the people who might have the evidence (at scale) don't want to do it. 3) the gateways really have no idea if PLPMTUD is being done, and sometimes it's better to just make things work. > Sprinkling bits to try to communicate with hops in between hasn't > worked for decades. Agreed. PMTUD is a fail. > Or use IPTFS and set your own max packet size sufficiently low? I think that this is the killer app for IPTFS. > I'm not convinced doing this between IPsec peers will solve any real > use cases. I am also skeptical, but I don't object to the work getting standardized. In particular, for networks where there are MTU constraints on the far side of the far gateway, telling the sending gateway about the MTU has a far higher chance of working than anything else. The sending gateway probably can send PTB ICMPs with better results. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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. 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. 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. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Wed, 2 Aug 2023, Michael Richardson wrote: Christian Hopps wrote: >> 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). You can't do that if DF=1, or IPv6. You can form big ESP packets and then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant cope with fragments. Why does any of this even matter? The applications should use PLPMTUD / DPLPMTUD ? Sprinkling bits to try to communicate with hops in between hasn't worked for decades. Or use IPTFS and set your own max packet size sufficiently low? I'm not convinced doing this between IPsec peers will solve any real use cases. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Christian Hopps wrote: >> 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). You can't do that if DF=1, or IPv6. You can form big ESP packets and then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant cope with fragments. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
"Panwei (William)" 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). 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. 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. :) 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:ipsec-boun...@ietf.org] On Behalf Of Daniel Migault Sent: Wednesday, August 2, 2023 12:56 AM To: Ben Schwartz Cc: Harold Liu ; ipsec@ietf.org 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 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 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 behavio
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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. 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. 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. 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:ipsec-boun...@ietf.org] On Behalf Of Daniel Migault Sent: Wednesday, August 2, 2023 12:56 AM To: Ben Schwartz Cc: Harold Liu ; ipsec@ietf.org 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 mailto:mglt.i...@gmail.com>> 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 mailto:bem...@meta.com>> 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 mailto:mglt.i...@gmail.com>> Sent: Monday, July 31, 2023 12:10 PM To: Ben Schwartz mailto:bem...@meta.com>> Cc: Harold Liu
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Hi,
FWIW, Here's what I was saying at the mic during the ipsec meeting @117. It may
have relevance to the discussion about EMTU...
You own the tunnel endpoints since you're configuring security tunnels on them.
Normal PMTU will work fine if, for some reason, you need your ingress to
discover the egress endpoint's nexthop MTU (red-side link) dynamically. This is
b/c your not going to configure your own tunnel endpoints to drop ICMP too big
packets and break it yourself. So, you don't need any new mechanism to discover
your own downstream red side link MTUs.
Also, I'm pretty sure that most transit routers are configured to never
fragment forwarded packets (it's a DDOS attack vector), so I don't think your
going to be seeing the outer ESP IP packet be fragmented either. This
functionality is so unpopular it was completely eliminated from IPv6, so it for
sure will never happen if your outer encap is IPv6.
Thanks,
Chris.
Daniel Migault writes:
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
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
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
Sent: Monday, July 31, 2023 12:10 PM
To: Ben Schwartz
Cc: Harold Liu ;
ipsec@ietf.org
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 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 <
bem...@meta.com> 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
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters wrote: > On Aug 1, 2023, at 12:56, Daniel Migault wrote: >> >> 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 > 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. Odd if you think it's all 1500 byte ethernet. And there are no further tunnels. Could come out of an ESP SA and try to go into an ESP-in-UDP SA, and it might not fit. Many people would like to use 9000 byte ethernet across VPN links. Such as the physical people. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Hi Paul, Please see my response in line. Yours, Daniel On Tue, Aug 1, 2023 at 2:15 PM Paul Wouters wrote: > On Aug 1, 2023, at 12:56, Daniel Migault wrote: > > > > > 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 > > > 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. > > 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. > > Paul > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
On Aug 1, 2023, at 12:56, Daniel Migault wrote: > > > 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 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. > 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? Paul___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 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 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 >> *Sent:* Monday, July 31, 2023 12:10 PM >> *To:* Ben Schwartz >> *Cc:* Harold Liu ; >> ipsec@ietf.org >> *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 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 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-
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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 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 > *Sent:* Monday, July 31, 2023 12:10 PM > *To:* Ben Schwartz > *Cc:* Harold Liu ; > ipsec@ietf.org > *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 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 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 > *Sent:* Sunday, July 30, 2023 9:28 PM > *To:* Ben Schwartz ; Daniel Migault > *Cc:* ipsec@ietf.org > *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 *On Behalf Of *Ben Schwartz > *Sent:* Saturday, July 29, 2023 8:01 AM > *To:* Daniel Migault > *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. > >
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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 Sent: Monday, July 31, 2023 12:10 PM To: Ben Schwartz Cc: Harold Liu ; ipsec@ietf.org 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 wrote: Hi Harold, It sounds like you're describing a different problem. Daniel mentioned a concern about cases in which "the encrypted ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Hi Ben, Please see my comments. On Mon, Jul 31, 2023 at 10:47 AM Ben Schwartz mailto:bem...@meta.com>> 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 mailto:40ericsson@dmarc.ietf.org>> Sent: Sunday, July 30, 2023 9:28 PM To: Ben Schwartz mailto:bem...@meta.com>>; Daniel Migault mailto:mglt.i...@gmail.com>> Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> mailto:ipsec@ietf.org>> 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 mailto:ipsec-boun...@ietf.org>> On Behalf Of Ben Schwartz Sent: Saturday, July 29, 2023 8:01 AM To: Daniel Migault mailto:mglt.i...@gmail.com>> Cc: ipsec@ietf.org<mailto: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 mailto:mglt.i...@gmail.com>> Sent: Friday, July 28, 2023 10:47 AM To: Ben Schwartz 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 t
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 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 > *Sent:* Sunday, July 30, 2023 9:28 PM > *To:* Ben Schwartz ; Daniel Migault > *Cc:* ipsec@ietf.org > *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 *On Behalf Of *Ben Schwartz > *Sent:* Saturday, July 29, 2023 8:01 AM > *To:* Daniel Migault > *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 > *Sent:* Friday, July 28, 2023 10:47 AM > *To:* Ben Schwartz > *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 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 on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Sent:* Thursday, July 27, 2023 9:32 PM &
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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". That's quite different from an MTU limit on the forwarding path, which can be dealt with using ordinary IP fragmentation and PMTUD. --Ben Schwartz From: Harold Liu Sent: Sunday, July 30, 2023 9:28 PM To: Ben Schwartz ; Daniel Migault Cc: ipsec@ietf.org 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd 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 On Behalf Of Ben Schwartz Sent: Saturday, July 29, 2023 8:01 AM To: Daniel Migault 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 mailto:mglt.i...@gmail.com>> Sent: Friday, July 28, 2023 10:47 AM To: Ben Schwartz 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 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 mailto:ipsec-boun...@ietf.org>> on behalf of Daniel Migault mailto:mglt.i...@gmail.com>> Sent: Thursday, July 27, 2023 9:32 PM To: IPsecME WG 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 e
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 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 On Behalf Of Ben Schwartz Sent: Saturday, July 29, 2023 8:01 AM To: Daniel Migault 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 mailto:mglt.i...@gmail.com>> Sent: Friday, July 28, 2023 10:47 AM To: Ben Schwartz 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 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 mailto:ipsec-boun...@ietf.org>> on behalf of Daniel Migault mailto:mglt.i...@gmail.com>> Sent: Thursday, July 27, 2023 9:32 PM To: IPsecME WG 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
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 Sent: Friday, July 28, 2023 10:47 AM To: Ben Schwartz 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd 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 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 mailto:ipsec-boun...@ietf.org>> on behalf of Daniel Migault mailto:mglt.i...@gmail.com>> Sent: Thursday, July 27, 2023 9:32 PM To: IPsecME WG 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
[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 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
