[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay attacks
So here's a discussion question for those who believe in IPSEC
sequence numbers: should they be handled in an algorithm-specific
way, or should they be a part of the generic AH protocol header?
(For certain MACs, e.g. those based on stream ciphers, replays are
automatically avoided; yet as far as I know these MACs have not
been used in practice much.)
As Steve Kent has noted, he and I changed our minds about sequence numbers
not because of rationale originally given, but because a new attack was
found. That is, the original proposal for sequence numbers in the IPSEC
header was to prevent th annoyance of the receiving process or protocol
by reinjecting packets. Since that's already a risk the receivers are
(or should be) engineered to handle, adding another layer of defense
seemed to be redundant.
The new threat is different: by proper use of replays, an enemy can
subvert the function of the IPSEC header. It is thus *necessary* to
have sequence numbering at the IPSEC level.
As to whether it should be algorithm-specific or not -- the attacks
don't depend on the characteristics of the particular cryptosystem used.
This means that any cryptosystem will need the function; to me, that's
a good justification for doing it right, in one place.
The sequence number must be big enough that no packet using it can
be replayed during the lifetime of a key. 32 bits is demonstrably
insufficient; if my arithmetic is right, at FDDI speeds such a counter
would cycle in just a few hours. 48 bits would suffice, though if
line speeds get much above 10 giabits/second we may have to cut our
key lifetime a bit.
Follow-Ups: