[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Granularity of authentication in swIPe
>I haven't had a chance to unpack the Usenix disk yet; as I recall, though,
>swIPe has a one-byte keyid, which is unacceptable to me. It also has a
>packet sequence number, which is a rather dubious construct that needs
>a *lot* of debate, at the very least.
The sequence number idea has already had a lot of debate. I guess it
needs more.
Since I was the one who originally proposed the sequence number
feature, I guess I should try to defend it. First of all, the term
"sequence number" is slightly misleading, because there is NO attempt
to use it to provide in-sequence delivery. The intent was solely to
help provide "at most once" IP datagram delivery in the presence of
hostile replay attacks during the lifetime of a single SAID.
My original motivation for this was as follows:
Most ciphers that operate on packets require some sort of nonce (e.g.,
an IV) to ensure that identical packets encrypt differently. Although
the IV could be part of the cipher-specific encapsulation, it seemed
like a general enough feature to consider making it part of the
standard IPSEC header. And if you make the IV a standard part of the
IPSEC header, then you can make it do double duty in suppressing
duplicates. This is much more convenient if the IV is a sequence
number, but in theory it doesn't have to be. It just makes the
bookkeeping easier.
Not to say that the bookkeeping would actually *be* easy. If you
assume that most packets arrive in order and are not lost (a fairly
reasonable, though not universally valid assumption) then a data
structure like that kept in a netnews .newsrc file could work well.
But the only general mechanism would be a bitmap large enough to cover
all of the packets to be sent during the lifetime of a single SAID.
But the mechanism doesn't have to be totally bulletproof to still be
useful. Since you only have to suppress duplicates for the life of the
SAID, so you can always bound the bookkeeping by just creating a new
SAID and blowing away the old one. You might even decide to do this
automatically if you seem to be under a denial-of-service attack.
So my question to the list is this: is there any kind of concensus
around my first point, which is that the concept of a crypto-seeding
IV is universal enough to warrant becoming part of the standard IPSEC
header, where it can then possibly be used to do other things as a side
benefit, like replay suppression?
Phil
Follow-Ups:
References: