[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
Bill,
----- Original Message -----
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: <hugh@mimosa.com>
Cc: Dan Harkins <dharkins@cips.nokia.com>; Henry Spencer <henry@spsystems.net>; IPsec List
<ipsec@lists.tislabs.com>; Hugh Daniel <hugh@toad.com>; John Gilmore <gnu@toad.com>
Sent: Monday, July 17, 2000 4:18 AM
Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
> Having just spent some time beating my head against a related issue
> (quick mode state management) in interoperability testing, it's clear
> that the whole phase-2 "message-id" (really "transaction id") and the
> implicit initialization vector chaining approach is just extremely
> fragile from a protocol point of view, leading to all sorts of
> finger-pointing when debugging.
>
> one commonly sees the following if a quick mode exchange which runs
> "slow" (particularly when you have logging, etc., cranked up all the
> way), leading one party to retransmit:
>
> - both packets are received; the first one is handled
> properly, advancing the IV and similar state in the phase 2
> transaction.
> - the second packet is decrypted using the new (wrong) IV
> state, resulting in a decrypted packet in which the first block of the
> plaintext is garbled.
> - the garbled packet is fed to the isakmp parser, where any of
> a number of things could happen before the parser decides the packet
> is too broken to live. almost certainly, it's not going to be able to find
> the HASH payload at all so it can't even verify the integrity of
> the rest of the message..
> - the receiver typically then sends a (spurious) NOTIFY
> message informing the sender that a message, broken in one of many
> possible ways, has been received.
The problem you have described is not a protocol problem, it is
an implementation problem. Nothing prevents implementation from
keeping last received packet (or hash of it) in SA state and discarding
any incoming packet if it is identical to the packet kept. At least
our implementation behaves this way and we have never encountered
your problem.
> An alternative case occurs when the initiator doesn't like the
> responder's reply, and just drops the phase 2 exchange state. the
> retransmitted message from the responder is then treated as a "new" QM
> transaction, which, as above, is garbled on decryption.
Again, it is possible for initiator to keep the state for a while
(as TCP does), although in this case it is less desireable and
can lead to potential DoS attacks.
> No, this isn't a "security flaw" in the protocol. It's simply
> non-robust protocol design.. it's exactly when retransmissions are
> occuring that you *don't* want to burden the network with additional
> spurious traffic.
I agree that protocol could have been designed a bit better in
this area (for example, it could have been possible to introduce
some field in ISAKMP header, say Message-Number-In-This-Exchange;
it must be authenticated, but not encrypted; this would have helped to
quickly detect retransmissions), but I don't think that current design
is "non-robust", it just require an implementation to be a bit more wise.
> - Bill
Regards,
Valera.
Follow-Ups:
References: