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

IPv6 Jumbo Payload and IPsec


Hi. I've recently worked with IPv6 and IPsec implementations,
and would like to ask the group some advice regarding treatment
of IPv6 jumbograms. You may already recall that IPv6 provides
for up to 2^32-1+40 byte packets using the Jumbo Payload option
described in RFC 2675. If this option is used, then the
actual length field in the IPv6 header is set to zero. Such
packets may not be fragmented.

I'm curious as to the effects this has on IPsec. Has any
of the folks supporting IPv6 IPsec actually implemented Jumbo
Payload support as well?

What is the purpose of the Jumbograms?

Why are the Jumbo Payload options classified as Hop-by-Hop
options? It survives end-to-end unchanged, doesn't it?

Are there any limits to the size of the packets with Jumbo
Payloads or is the full 32 bit packet length field in use?

Is it mandatory to support Jumbo Payloads? RFC 2675 states
as follows:

   Jumbograms are relevant only to IPv6 nodes that may be attached to
   links with a link MTU greater than 65,575 octets, and need not be
   implemented or understood by IPv6 nodes that do not support
   attachment to links with such large MTUs.

But what does this mean? If I have links with MTUs of 1M, but
my IPsec or IP forwarding doesn't allow quite as much in between,
am I allowed to send back an ICMP?

What are the Denial of Service aspects of Jumbo Payloads?
For instance, assume you have a 1 Gbit/s hw or CPU to do
encryption. Then you get a Jumbo Payload of 4 * 8 Gbits,
and spend the next 32 seconds handling this one packet.
Granted, even receiving the 4 Gbyte packet will take a
lot of time unless one is running pure IP over WDM fiber
and has lots of buffer space... but let's assume you are
running on such machine but with a low-speed CPU and
IPsec mainly targeted to protect some control traffic.
Then somebody sends a big packet claiming to be a real
IPsec packet... at 10 Mbit/s even integrity check will take a
long time, especially if the CPU runs a single-threaded kernel
mode implementation...

How would one go about testing the Jumbo Payload? In particular,
how would you test boundary cases such as ESP padding causing
an overflow beyond 2^32-1+40?

Jari
---- 
Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480
Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com
Private WWW: http://www.iki.fi/jar. Standard disclaimers apply.
Follow-Ups: