On Sat, 3 Jul 2004, Herbert Xu wrote:
> Hi:
>
> This is a proposal of a method of detecting the path MTU that can be
> applied by IPsec keying managers (e.g., openswan/racoon).
>
> My idea is to use the information available in TCP MSS clamping to
> help IPsec gateways. This can be done by having the gateways
> establish a short-lived TCP connection with each other for the
> purposes of determining the MTU. Obviously this TCP connection will
> need to be authenticated. If the connection cannot be established
> (e.g., if an attacker is preventing the gateways from doing so), then
> we can fall back to the existing MTU discovery mechanisms.
>
> If however this connection succeeds, then we can deduce the path MTU
> from its MSS settings. We can then apply that MTU to the path taken
> by the IPsec SAs. This makes any ICMP black holes between the gateways
> invisible to the end users as long as the information provided by
> TCP MSS clamping is accurate.
Interesting idea - tcp/500 connection (or maybe it should be port 4500, to
deal with NAT boxes. I assume you want to do this as early as possible,
eg: Phase 1, however until we have a PH2 we can't do a secure TCP, only
authenticated.
> The advantage of this over the approach taken by KLIPS (the FreeSWAN
> kernel implementation for IPsec) is that we do not transmit fragments
> where possible which is the motivation behind PMTU discovery. The
> advantage of this over the current implementation is that this will
> work correctly in environments where there are local ICMP black holes
> that are known through TCP MSS clamping.
>
> Comments?
I like it it in concept - I'd be interested to see how much of a hack is
needed to implement it in reality. Should definatly use a VendorID to
state whether or not each side supports it, so we don't open TCP
connections and let them timeout/die/be hijacked.
--
Ken Bantoft VP Business Development
ken@xxxxxxxxxxxxx Xelerance Corporation
sip://toronto.xelerance.com http://www.xelerance.com
|