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
