RE: [IPSEC] proposal for PMTU handling in IPSec for IPv4

RE: [IPSEC] proposal for PMTU handling in IPSec for IPv4

[Zhao, Forrest]

Hi, Alexey

Thanks for your reply!

> 3 Every time the source output the data packet, it should check each
SA
> associated with the specific secure policy. If it find any one
> xfrm_state has the meaningful pmtu value, then it should calculate the
> resulting PMTU and send  <<ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED>>
message
> to the real source in the secure policy selector. This checking point
> should be in function: dst_output();.

I am not so sure about this.

First (and a bit different) thing: pmtus of SAs should be taken into
account when we calculate dst->pmtu. So, each pmtu event should cause
recalculation of dst->pmtu on the bundle. It is necessary, when
tunnel is used for locally generated packets, we should prepare
good frames which will not fail while being transformed.

I think I must have overlooked something, but I can't figure out why it
is necessary to recalculate dst->pmtu on the bundle when each pmtu event
occurs. What's the special aspects related with dealing with locally
tunneled packets? Thank you very much for your detailed explanation.

The second thing is painful. We have to send icmp for original packet
as it entered our host. So, pmtu checks at each trnasformations is
not so easy. There are two variants: one was suggested by Dave,
namely, we store required 8 octets of original skb somewhere in skb head
and proceed like you proposed, checking that transformed skb still fits
to pmtu. The second variant is just to check against precaluclated
dst->pmtu on the entry to dst_output() before doing transformations.
Logically it is cleaner, it is simpler and faster, but it will result
in underestimation of mtu for esp due to alignment paddings and for
IPCOMP it will be totally unfair.

Actually, it was the point where Dave, James and me stopped.
Dave's variant looks more promising.

I agree with you and vote for Dave's variant! I omitted the alignment
padding issues previously.

Then since Dave's variant is a good solution for handling PMTU in IPsec
for IPv4, do you think it's appropriate if I write some patches for it
now? Is there any other tricky issue to be resolved for handling PMTU in
IPsec for IPv4 until now?




Thanks,
Forrest