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

Re: IPv6 Jumbo Payload and IPsec

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

We don't have jumbogram support yet.

> What is the purpose of the Jumbograms?

To allow the full use of large MTU links.  Most of these large MTU links
connect supercomputer-class machines.  (And I'll bet small sums that many
instances of such links are physically secure and disconnected from hostile
networks.)

> Why are the Jumbo Payload options classified as Hop-by-Hop
> options?

Because it needs to be seen immediately, in case of two jumbo-sized MTUs.

> It survives end-to-end unchanged, doesn't it?

Yes.

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

Nothing save the link MTU stops the packet size from reaching its maximum.

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

I believe so.  You may wish to verify this with someone more IPv6-savvy.  My
local IPv6 clue sources aren't in the office yet.

> What are the Denial of Service aspects of Jumbo Payloads?

The same as regular payloads... except bigger!  :)

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

Yep.

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

Only way this would happen is if your adversary has access to your high-MTU
link.  Given what I said earlier, this is a low-probability event.

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

The same way you would an ordinary packet - only obtaining the length a
different way.

Dan
References: