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

Re: IPv4 Security redux



I strongly agree that the ipsec charter ought to be strictly limited to
IPv4.  It's impossible to anticipate every future need of anything that
could conceivably become a new IP, and attempting to do so is the surest
path to OSIfication (i.e., producing lots of paper but no usable
product).

Our protocol may need replacement some day, but so what? To my
knowledge, we're the first to talk about network layer security in the
Internet. There's no experience base, so gaining one is a worthwhile
goal in itself. And what we learn will put us in a much better position
to design its replacement if that should become necessary.

I advocate a highly pragmatic approach here, with a strong emphasis on
ease of implementation and on solving immediate, known problems. Even
though this is nominally a host-to-host protocol, I see the first
implementations being in encapsulating gateways used to join trusted
networks (e.g., internal corporate subnets) via untrusted ones (e.g.,
public Internet carriers). This means supporting every existing
transport protocol and application, robustly designed or not.

In particular, I think we need sequence numbering to protect against
replay attacks. Although it is theoretically correct to cite layering
and argue that internet transport protocols are supposed to protect
against packet duplication, in practice a lot of existing Internet
transport protocols and hosts rely on non-intentional duplication being
rare, which it fortunately is, especially for long-delayed duplicates. A
good example is the ARNS package when used to encapsulate Appletalk
packets inside UDP. It's my understanding that Appletalk doesn't
handle duplication very well at all.

Even TCP, whose designers had an almost pathological obsession with
duplicate packets, has problems when hosts lose state (e.g., when
they're rebooted). Many TCPs reuse the same sequence of port numbers and
initial sequence numbers each time they're rebooted, creating an
opportunity to replay packets recorded from before the reboot.

If the ipsec protocol ran on a host-to-host basis, this problem could be
avoided by simply requiring the hosts to rekey each time they reboot.
But given the likely popularity of intermediate encapsulating gateways,
I don't see any easy way to solve this problem without sequence
numbering.

Re some of the other fields, I question the need for a "security
association identifier" (or key identifier, or whatever you call it).
Given that every modern operating system I'm aware of has a trusted
kernel that applications already rely on to protect themselves from each
other and from the outside, I really don't see the point of having more
than one active cryptographic key per host pair managed by these
kernels. A host can determine the appropriate key to use for each packet
solely from the address of the other host; it doesn't need an explicit
key ID.

So as I see it, here is what should be in the ip security header:

Flags - indicating the presence or absence of an authenticator in this
packet, and whether the packet is encrypted. 1 byte. Sent in the clear,
included in the authentication computation.

Protocol - the value that would have gone into the IP Protocol field had
the security protocol not been used. This could be, eg., 17 (UDP) or 6
(TCP) if the ip security protocol is implemented on the end host, or it
could be 4 or 94 (two different values for IP-in-IP encapsulation) if
this system is providing secure IP encapsulation on behalf of other
hosts. 1 byte. Sent encrypted, and included in the authenticator.

Packet serial number - used to thwart replay attacks. When this number
is lost (e.g., due to a reboot) or wraps around, rekeying is required.
Given this last rule, 2 bytes should be plenty. Included in the
authenticator. Not sure whether it should be encrypted or not; leaving
this in the clear makes it easier to filter out a heavy flood of replays
without spending cycles decrypting them first.

Authenticator - Optional, possibly variable length. Algorithm could be
negotiated during key exchange. It would probably be something like the
MD-5 hash of the protected portion of the packet, seeded with the
current shared key.  Up to 8 bytes. Not included in the authenticator
(e.g., considered to be zero when computing and verifying the
authentication). Should probably be sent in the clear, since encrypting
it doesn't seem to buy anything, and would again make it easier to
filter a flood of malicious traffic without spending cycles on
decryption (which is likely to be much slower than MD5 hashing).

So, that means 4 bytes of fixed overhead, plus possibly 8 more for
the authenticator. And everything lands on the right boundaries
for performance.

What else do we need?

Phil



Follow-Ups: