Subject: more on INITIATE

From: Michael Thomas <[email-masked]>
Date: Thu, 17 May 2001 13:35:28 -0700 (PDT)

I've been going through the archives trying to
figure out what the protocol needs to do for the
INITIATE that Derek suggested in January.  What we
agreed to at ietf50 was to require a round trip
reachability test to mitigate the DoS attacks of
somebody just spraying spoofed INITIATE's. There
seems to be good consensus for this. However in
thinking about this, I realize that we're not
really done here.

1) The server sends the INITIATE, but initiate 
   _what_? What does the client do? How does
   it know whether the server wants to do a
   CREATE or a DELETE? How does it know what
   proposals to make? How does it know the
   selectors need to be? With the packetcable
   wakeup, all of these things were implicit
   (CREATE an SA toward the CMS)

   Remember that the INITIATE is, by definition,
   *unauthenticated*. What prevents tampering
   loss of privacy if you put the semantics of
   the CREATE, etc in there?

   I'm really not sure what to do here.

2) GetTGT: Derek's proposal used the GetTGT
   request as the reachability test, which
   is fine, but seems sort of odd when the
   client already has the TGT or service ticket.
   Should we create a NOP kind of command to
   test for reachability, or just stick with
   the GetTGT (perhaps without request any TGT)?

3) Currently, the protocol requires that the
   initiator run the "optimistic" approach
   to creation of SA's. This is fine when the 
   initiator starts this, but could lead to
   a DOS attack since the optimistic approach
   requires that the initiator install SA 
   state before sending the CREATE. I'd like
   to propose that we have a new "pessimistic
   create" flag which informs the other side
   that we haven't installed state and that
   you have to do a full 3-way handshake.

	    Mike