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

ICMP must fragment and IPsec

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

    Alan> This is becoming more and more obvious. Also IPSEC still
    Alan> doesnt address the ICMP MUST FRAGMENT tcp denial attacks

>>>>> "Perry" == Perry Metzger <perry@piermont.com> writes:
    Perry> What attacks would those be?

    Alan> Send an ICMP MUST FRAGMENT MTU=68 to someone running a secure
    Alan> session. Now they can pick either
    Alan> 
    Alan> 1. Ignore it because it isnt signed - doesn't work because the
    Alan> packet may be real mtu lowering info
    Alan> 
    Alan> 2. Believe it and watch the peformance crash
    Alan> 
    Alan> The problem is this is the one case where we have to trust a
    Alan> potentially unsigned frame if we want to do TCP mtu
    Alan> discovery. If you drop MTU discovery from secure TCP sessions
    Alan> it seems ok

>>>>> "Vernon" == Vernon Schryver <vjs@mica.denver.sgi.com> writes:
    Vernon> You omitteded the most reasonable response:

    Vernon>  3. ignore it because 68 is so ridiculously tiny that it
    Vernon> is obviously bogus and if the path MTU were that bad, you
    Vernon> may as well close the connection.

    Vernon> "Be generous in what you accept" is not the same "be
    Vernon> stupid and do not sanity-check anything."

    Vernon> Reasonable systems should drop any demands for an MTU less
    Vernon> than 128 and probably anything less than 256.  256 is

  Vernon's suggestions seem rather good judgement, but the need for
some kind of authenticated Path MTU discovery is important, in my
opinion. 

  One way might be to have an ICMP or TCP option that requests the
other end to provide a response, giving the size of the largest
fragment received. This would be enclosed in the SA that the TCP data
is flowing in. This is in some sense a variation of the TCP MSS option.

  A TCP option is probably harder to implement, and harder to deploy,
but has the advantage of not requiring another packet, and not
requiring any dances with ISAKMP per-protocol/port ("connection") SA
keying. However, we already have to deal with making sure that other
TCP related ICMPs get transported/tunnelled properly. [ICMP_UNREACH,
ICMP_SOURCEQUENCH, are there others?]

  An ICMP option has the advantages that it doesn't require TCP to
know anything about the fragmentation of the packets, which is just
gross. Still, ICMP then needs to know, but that might be easier for
some people to implement.
  
  Another possibility would be to have the receiver advise the sender
in a TCP option, whenever the max-size fragment received in past 2MSL
changes by more than 10%. This might be more effective in the cases
where the route changes in a way that affects the MTU, than Path MTU
discovery, which as far as I understand, only is done at the beginning
of the connection. 
	[... not according to rfc1191. The DF bit is set on all
	packets, so PMTU is always done]
	
  I can't think of many cases in the current deployed internet where
the MTU might change during a connection. Usually, the smallest MTU is
on the edges at that 28.8 (or that 2400 baud modem) link, and that
isn't likely to change suddendly. I can see mobileip possibly changing
this. If/when mobileip is deployed en-mass, it will definitely include
IPsec.

  Getting Path MTU information back to the sending TCP is not an
unsurmountable challenge to VPN uses of IPsec, but it isn't easy. In
the case of "Virtual Circuit" style security gateway traversal (see
draft-richardson-ipsec-traversal-cert-00.txt), there are several MTU's
involved: the end to end MTU, and the MTU between each security
gateway.

  Both are important to know. An argument against the TCP option (and
for an authenticated ICMP) is that it would not be usable with non-TCP
things, like ESP. 
  Note: when I say authenticated ICMP, I mean using either ESP or
AH. Probably the ICMP is no less sensitive as the data, so ESP if the
data is encrypted.
  
  In conclusion: an ICMP need frag message placed in the tunnel

   :!mcr!:            |  Network security programming, currently
   Michael Richardson | on contract with DataFellows F-Secure IPSec
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.

  
  
  

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM62XlKZpLyXYhL+BAQH9dAMAuR/oq9ylmAAvBl7Kedg/v9O4Z3/5kwwJ
gzJ8WqQ8FIKXqPf7GYHNsIQxNBDztZzgZ/c+9r7sbRTqSVeelvcNr51lLp+fBhHz
3OFufP+Gn0W4TOFIPaPIbOtPf2d+rIkH
=SIJJ
-----END PGP SIGNATURE-----