RE: IKEv2 (son-of-ike) draft

["Walker, Jesse" <[e-mail]>]

Hi Radia,

Dan, Charlie, and you have done a nice job with this draft document. Thanks
for making this effort; it is a very hard job. I especially commend the
lucid key roll-over discussion, as the lack of one was a devil tormenting
implementors of the RFC 2401-2412 series.

With that in mind, the following text on page 21 from Clause 5
"Informational (Phase 2) Exchange" jumped out at me:

   ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each
   direction. When an SA is closed, both members of the pair MUST be
   closed. ... The recipient MUST close the designated SAs.
   Normally, the reply in the Informational Exchange will contain delete
   payloads for the paired SAs going in the other direction. There is
   one exception.  If by chance both ends of a set of SAs independently
   decide to close them, each may send a delete payload and the two
   requests may cross in the network. If a node receives a delete
   request for SAs that it has already issued a delete request for, it
   MUST delete the incoming SAs while processing the request and the
   outgoing SAs while processing the response. In that case, the
   responses MUST NOT include delete payloads for the deleted SAs, since
   that would result in duplicate deletion and could in theory delete
   the wrong SA.

This does not sound quite right. The Internet between the SA source and sink
is a large re-ordering buffer, so the Delete can arrive before many
already-transmitted data packets protected by the SA.

It might be that this problem is not worth fixing, as the packet loss is
transient and infrequent and any solution outweighs the introduced
complexity, and I can accept this conclusion. However, as network speeds
increase, the consequences this kind of reordering will become more evident
and irritating, as more packets can be buffered, so it seems like we should
at least have the discussion at least once.

Let us call the communicating peers A and B, with A initiating the Delete;
the A to B direction will be denoted by A->B, and analogously B->A for the B
to A direction. Intuitively A will roll-over from the old A->B SA to the new
by deciding to transmit on the new replacement A->B SA but receive on both
the old and the new B->A SAs, and then send the Delete. Once it has made
this decision there is no reason for it to maintain the old A->B SA, because
it knows it will never use this for packets it sends to B.

When B on the other hand receives the Delete, it doesn't know that it will
receive no more protected datagrams for the old A->B SA. A faces a similar
dilemma when it receives B's Delete response.

It seems like there are two potential difficulties here. First the deletion
of the half-duplex SAs are tightly coupled to occur together, and second,
the receiver of a Delete doesn't have enough information to intelligently
decide when to effect the delete of is old incoming SA.

What seems needed is something like incorporating the SA's last sequence
number sent into the Delete payload, and then adding a new state to an SA to
allow the timing of the Delete of an SA to be decoupled somewhat from that
of its bretheren in the opposite direction; perhaps the incoming SA has to
be timed out after the outgoing one has been deleted, if it has not received
to the end of the reported sequence space.

-- Jesse

-----Original Message-----
From: Radia Perlman - Boston Center for Networking
[mailto:[e-mail]]
Sent: Monday, November 19, 2001 11:55 AM
To: [e-mail]
Subject: IKEv2 (son-of-ike) draft


And to answer some of the recent email on the list...this
protocol does maintain the phase 1/phase 2 notion, but sets up
both phase 1 and phase 2 in a single 2-round-trip exchange.
After the initial exchange, additional SAs can be set up,
or the SA can be rekeyed, with a single round trip. And it
does identity hiding of both ends.

Most of the work was in rewriting the three documents into
a single self-contained document, and cleaning up the "networking"
type issues and overly complex encodings such as
the SA payload.

Radia
------------- Begin Forwarded Message -------------

To: [e-mail]
From: [e-mail]
Subject: IKEv2 (son-of-ike) draft
MIME-Version: 1.0
Content-ID: <[e-mail]>

   This draft was submitted but hasn't shown up yet in the repository
(the I-D editor is, no doubt, swamped) so in the interest of giving
people more time to look at it prior to Salt Lake here's a link:

             http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt

Please send comments to the list.

   Dan.



------------- End Forwarded Message -------------