[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv4 Security redux
Well, frequent rekeying caused by a small sequence number is a problem
only if rekeying is expensive. By "rekeying" I mean the automatic
establishment of a new crypto key for the host pair. Ideally this would
be the product of a Diffie-Hellman exchange, but a scheme based on a
symmetric cipher and a shared master key would also work.
The communication overhead from rekeying is negligible with a 16 bit
sequence number; I can't get excited about adding, say, 3 packets to
every 65,536 data packets. On the other hand, I do get excited about
every additional byte that we add to every packet (see later).
Depending on the key generation algorithm, the compute overhead of
rekeying may or may not be a problem. Comments?
I wonder if we could somehow use the existing IP ID field as the
security protocol sequence number, instead of adding one explicitly to
the security header. This may complicate some implementations where the
IP level adds the ID field automatically. But I think it's supposed to
be possible for the upper layer protocol to specify an ID field to IP
when it sends a datagram (my code does, although I don't use this
feature yet). This would be one way to get a 16-bit sequence field
without spending two bytes on it in the security header.
Few seem to agree with me that the key ID is superfluous. So given
that we want it, how big does it have to be? Could it share a byte
with the flags that indicate whether the packet is encrypted and/or
authenticated? Is a 4 bit key ID enough?
I should say where I'm coming from on all this. I run the Internet
protocols over some very slow and expensive links, such as dialup modems
and cellular radio. Header overhead is an absolutely critical concern to
me. We're already starting with a significant disadvantage because the
kind of protocol we're discussing will break Van Jacobsen TCP/IP header
compression. So I'm trying to avoid making things even worse by adding an
overly large security header.
At the same time, I'm sensitive to performance concerns on fast
networks, so I like fixed-sized, aligned fields. This means making some
tough choices about exactly what goes where into the security header.
The OSI approach of tossing in everything but the kitchen sink and
making everything optional and variable length is not my idea of an
efficient solution.
Phil