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

RE: INITIAL-CONTACT issues




A question I have in this regard is

Isn't the problem of state cleanup faced by IPSec end systems
similiar to TCP state cleanup. TCP end-points can be left hanging
if the peer reboots. It is my understanding that TCP overcomes this
problem by providing KEEPALIVE mechanism. Can IPSec not do the
same thing and make use of KEEPALIVE mechanism for this purpose.

Another question I have in this context is

Many of the state machine problems IPSec is trying to solve
(like timeouts, race conditions due to out-of-order and
dropped messages) all seemed to be similar to one solved by
TCP state machine. So why not use TCP transport to implement
IKE state machine. The RFC's don't seem to perclude using
TCP as a transport. 

Is there anything in the IKE design that percludes using
a reliable transport? What am I missing?

   Thanks,
-- sankar --


-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Wednesday, April 28, 1999 5:10 AM
To: Niklas Hallqvist; ipsec@lists.tislabs.com
Subject: RE: INITIAL-CONTACT issues




---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: Niklas Hallqvist [mailto:niklas@appli.se]
> Sent: April 25, 1999 6:16 PM
> To: ipsec@lists.tislabs.com
> Subject: INITIAL-CONTACT issues

<snip: Niklas' comments on other issues deleted>

> Last, RFC 2407 in 4.6.3 says that INITIAL-CONTACT MUST NOT be sent in
> Aggressive Mode.  This is all fine by me (although I could envision
> the initiator send his INITIAL-CONTACT in the last message if he chose
> to encrypt it, which is at its option).  I bring this up because
> draft-jenkins-ipsec-rekeying-01.txt has some text that makes
> aggressive mode useless if we follow these rules, in 3.1:
> 
>      Initial Phase 1 SA Negotiation:
>       -initiator MUST use INITIAL-CONTACT notification
>       -responder may use INITIAL-CONTACT notification
> 
> Now, there is at least one voice stating that aggressive mode is
> useless anyhow, so maybe this is moot.  If it is not, however, I
> suggest Jenkins change his text to cover aggressive mode and talk
> about the options of sending INITIAL-CONTACT in a separate
> Informational Exchange (thus without guarantee of delivery) or as
> extra payload(s) in the first Quick Mode (which may not ever occur).
> I guess that is the best one can do in aggressive mode?
> 
> Comments?
> 
> Niklas
> 
> 

In the document, I did not discuss specific issues such as the
use of INITIAL-CONTACT with the phase 1 modes, so your question
is a very good one.

What I would like to see is a clarification of the logic. Here
is the text referred to:

   These messages MUST NOT be sent in Aggressive Mode exchange, since
   Aggressive Mode does not provide the necessary protection to bind the
   Notify Status Message to the exchange.

Is this comment still valid if the third aggressive mode message
is sent encrypted?

The INITIAL-CONTACT notification is important for recovery of
systems, so I would like to see more discussion with respect
to this issue.

Tim