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

Re: ICMP must fragment and IPsec


  [I'm hesitant about continuing to post this to both lists, but I'm
not sure where else it should go. I know that it doesn't really fit
into either charter, since we aren't documenting TCP bugs that need
fixing, and aren't discussing the things that we REALLY need to finish
to terminate the IPsec group. 
  Please give me advice by private email. Maybe I should write this up
as a draft, since I can see it getting more fleshed out in my mind.]

>>>>> "Vernon" == Vernon Schryver <vjs@mica.denver.sgi.com> writes:
    Vernon> What is this "other end"?  If talking to the other end of
    Vernon> a TCP connection were enough, then the MSS negotiation
    Vernon> would be enough and the Path MTU Discovery mechanism would
    Vernon> not be needed.  In fact, the MSS negotiation is often not
  I am assuming that packets that are sent that are too big, or become
too big due to n-levels of ESP/AH transport/tunnels will be
fragmented if the DF bit is not set.

  How much the packet gets fragmented can be determined by the
receiving host and/or tunnel end-point: it can observe the largest
fragment that was successfully received and participated in
reassembly. This information can be relayed to the sending host via an
ICMP Datagram Too Big message that can be put into the tunnel.

  This appears to screwed up by multiple paths with different
MTUs. However, it is easily fixed by only taking PMTU information from
packets that were fragmented: a larger packet that arrives intact
clearly took a different route, so it doesn't matter. Eventually, if 
the correspondant nodes can adjust their PMTU appropriately, all
packets arrive unfragmented. Clearly, the rate that ICMP's are sent
needs to be limited to not more than one per RTT.

  This works well on the end system that reassembles the packets. So,
getting an estimate of the PMTU from a transport mode, or tunnel mode
terminating on the end node is easy.
  If the tunnel doesn't terminate on the end node (but on a security
gateway), then one observes that the gateway must reassemble the ESP
or AH packets to terminate the tunnel. The gateway node can there 
	a) send an ICMP (in transport? or tunnel?) to the originating
	gateway, informing it of the PMTU that it sees, and the 
	originating gateway will send an ICMP to nodes that set the 
	DF bit when they do normal PMTU.
	b) alternatively, the PMTU between gateways could be
	communicated with an ISAKMP message.

	c) send an ICMP through the tunnel, to the TCP originating
	(TLO in the terminology of my traversal draft) node. The TLO
	sees this packet just like it would when it got ICMP messages
	when security wasn't present. However, it never sees the 
	routes that were tunnelled through, but the far end tunnel
	point would collect all that info for it anyway.
  BTW: not all current IPsec implementations do the right thing with
the DF flag. In theory, a DF flag on a packet going into a tunnel
should cause the tunnel wrapper to have the DF bit set, and the ICMP
Datagram Too Big messages adjusted in size and passed back to the
originating host. This assumes we can trust them. At least one
implementation in Detroit dropped the packets immediately, since the
new packet size didn't fit the outgoing interface's MTU, so the ICMP
would have been trusted in that case. My recommendation is to never
set the DF bit on the outside packet until you can deal with the
ICMP. That is, the problem is punted for a future working group, but
it means that IPsec VPN tunnels become non-compliant routers since
they don't honour the DF bit.
    Vernon> The trouble with authenticating path MTU information
    Vernon> (regardless of its form) is key distribution.  How would

  My position is that you can't distribute the keys. Please see my
draft for another place where it appears the intermediate security
gateways need the keys.

    Vernon> The only response to worries about path MTU messages, as
    Vernon> well as source quences, port, net, and host Unreachables,
    Vernon> and many other such indications is to be to cross your
    Vernon> fingers and ignore any that would have serious
    Vernon> consequences, such as an message telling you to use an MTU
    Vernon> of 68.

  I think we can do better than that.

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

    Vernon> There is a vast amount of topology on the edges, what with
    Vernon> ATM (9180), FDDI (4352), Ethernet (1500 or 1492), PPP (256
    Vernon> to more than 1500), and Frame Relay.

  But, do any of these things *change* during the course of a TCP
  While the routing on the backbone might change, my guess is that the
MTU between backbone nodes is almost always going to be more than the
1500 typical of a T1. I guess, two networks, that do ATM with their
supplier could get a much lower MTU if the supplier's ATM backbone
goes down, and the move their backup T1s. 

    Vernon> Besides, if you stay away from the edges and in the center
    Vernon> where routes don't flap among links with different MTU's,
    Vernon> you may as well fix your MTU=1500 and forget Path MTU
    Vernon> discover.

  Yes, there is this option.

    >> Getting Path MTU information back to the sending TCP is not an
    >> unsurmountable challenge to VPN uses of IPsec, but it isn't
    >> easy.

    Vernon> On the contrary, I think the key distribution problem is
    Vernon> insurmountable and makes authenticated path MTU
    Vernon> information impossible.  For example, look at any real

  I agree: trying to get the ICMP Datagram Too Big messages
authenticated is not possible. 
  I don't agree that getting authenticated PMTU information is

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

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