[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Path MTU Discovery
-----BEGIN PGP SIGNED MESSAGE-----
In message <199702062058.MAA22972@kebe.eng.sun.com>, Dan McDonald writes:
>
>An encrypting router often has a "tunnel interface" that'll have properties
>like:
>
> tun0: 10.69.0.0/16 --> 10.9.1.25
Not necessarilly. Virtual interfaces might not be used, or you might
have more than one SPIs using the same interface. Per SPI(-chain) MTUs
need to be kept. If you have a router that behaves as you describe,
then you don't need any other provision.
>BTW, by PathMTU discovery to the endpoint, I mean that the router (because it
>is originating packets now, from its address to the tunnel endpoint) has a
>cache-entry/host-route/whatever for the tunnel endpoint. That entry can be a
>repository for intermediate Path MTU information.
Which is the same as keeping that information on a per-SPI(-chain)
basis, if you don't use ViFs.
Another point is that fragmentation checking should be done before any
IPsec handling takes place (easier and faster).
>Now let's say there's ANOTHER layer of encryption between the router above
>and its tunnel endpoint of 10.9.1.25. THAT router may send an ICMP toobig to
>OUR router (10.10.20.20), saying the path to 10.9.1.25 has a smaller MTU than
>what I think. Now, because of the multiple nestings of IP, I can't percolate
>that ICMP toobig all the way back to the originator, but it will eventually
>percolate back.
Only if you can associate a packet "flow" with the ICMP message; easy
to do if you use a ViF for each tunnel.
>As for original TCP MSS, which needs to be set, IP must be able to send a
>hint to the particular TCP session indicating that IP security will lower the
>effective MSS for this TCP connection. I say it must only alter a single TCP
>session because IP security should use per-endpoint security properties where
>possible. See Bellovin's USENIX Security '96 conference paper for details on
>why. See draft-mcdonald-simple-ipsec-api-00.txt for how an application may
>exploit this.
Agreed. I just raised this because i'm not sure how many
implementations actually do this.
>Good point, and it applies to ICMP messages of all shapes, sizes, and
>flavors. It's possible an intermediate router could send an ICMP with AH on
>it, that way I have reasonable assurance it came from a router with that IP
>address.
That would mean establishing SPIs with all intermediate routers in
advance (on the fly might be too slow an approach). An then there's
the issue of verifying that the router is actually in the path (and
not some random "router" that established an SPI with us).
>Stock 4.4 is broken w.r.t. trying to perform Path MTU discovery. FreeBSD has
>one solution for doing this with IPv4. The NRL IPv6 code has another
>solution that it implements on the IPv6 side of things.
I was actually refering to initial mss (although i guess the interface
MTU is also used for PathMTU discovery - have to check the code).
So TCP has to "forsee" whether a packet will go through IPsec, and if
so what will be the size overhead.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMvqlyL0pBjh2h1kFAQHsaQP+KIPs/A05ehCPeYAnsy+VcCZCWqSnJSNI
RV7xkSb8parnQ5AyUybzWRB6bfubcqZ4qXEoOLdW8ErfUes0ei6eIgvW08Hs+uBQ
b3VsB0k1isVVzpQG+zxTjP8Jgd7GaqU76zon2OGcXOvoyXu6Fnx5gyJnvanlxu4B
qmAV4ltrPH4=
=Cx6g
-----END PGP SIGNATURE-----
Follow-Ups: