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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello!

> 1 Add a new data field "u32 pmtu" to struct xfrm_state, this new field
> is used to record the PMTU value associated with the specific SA=20

Yes.


> 2 when the source receive the <<ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED>>
> message, if the source find the SA using daddr, SPI and proto, it should
> store the MTU in xfrm_state.pmtu

Yes.


> 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.

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.


> 4 According to the PMTU Aging, I haven't got a clear idea. Maybe you can
> give me some hint.

Well, it is not top goal. I think it is to be done like IPv4/6 do:
pmtu changes set some timeout and when it expires pmtu is reset.

Alexey
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux