Hi Valery,
This is not a different problem, because whatever solution we choose, we
must ensure the whole system is functional: both IKE and IPsec. Routers
that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too.
Thanks for pointing out Sec. 8 to me. I suppose you are right about the
behavior of implementations in the case of ESP-in-UDP, but from a
formalistic point of view, note that:
- RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP).
- RFC 3948 (IPsec-in-UDP) says nothing about fragmentation...
So we have a hole here.
By the way, I'm not sure that UDP packets are still typically small.
There's more and more video on the Internet, and I'm sure some of it is
NOT on Skype.
Thanks,
Yaron
On 06/11/2012 08:37 AM, Valery Smyslov wrote:
Hi Yaron,
I think this is a different problem from dropping UDP fragments, and,
from my point of view, less important. For most of UDP traffic this is
not an issue, because packets are small.
For TCP traffic IPsec gateway usually copies Don't Fragment Bit
to outer IP header, and usually this bit is set. If some intermediate
router has smaller MTU, it should drop packet and send ICMP Destination
Unreachable. Having received it IPsec gateway may store needed MTU value
in SA and then report
this value to any host in protected network that tries to send bigger
TCP packet.
This behavior is irrespective to whether ESP-in-UDP employed or just
plain ESP,
and is documented in RFC4301 section 8.
Regards,
Valery Smyslov.
Hi Valery,
There's something I'm missing here. Let's say we go for a solution
where we fragment IKE packets into pieces of 576 bytes, at the
application level.
Now, how do we determine the length of the ESP-over-UDP packets? Are
you suggesting we fix them at 576 too, or do we need to have a
(proprietary) path MTU discovery for this to *really* work?
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
