Transition state thoughts

Hi Hugh,


Here are my thoughts on the transition stuff.


Cheers,

Claudia


START STATE	END STATE	ACTION

General Ideas
-------------

any		block		Block.

any 		clear		Clear.

any 		same as start	No action needed.
(without conn)

any		same as start	Could either leave old conn up, or try to 
(with conn)			rekey. I see no reason to rekey at this time:
				it adds to clutter without being necessary.
				Below, I have put "No action" for these cases.

any	  	clear-or-oe	Treat as clear. Allow conn if requested.
(without conn)			

any		clear-or-oe	This is more tricky. Except in the 
(with conn)			clear-oe->clear-oe case, we want to rekey.
				But, due to the asymmetry of key distribution,
				we can't count on being able to do this.
				Can we force the other side to rekey by
				sending a Delete SA? In the interim we could
				send packets in the clear, or keep the old
				connection. It seems in keeping with the
				spirit of the policy to do the second;
				see more specific examples below.


block		any		Try connection. Fail to failureshunt.
							
clear		any		Try connection. Fail to failureshunt.

any		private		Hold packets while you try to negotiate
(no connection)	or oe-or-clear  new connection. Rather than assuming that
				the correct interim action is a product of the
				start and end states, it may be best to assume 
				the new one is what the user really wants, 
				starting now. In particular, the old policy
				may have been a mistake and/or the application
				layer may have just started trying to contact
				the peer. This argues that information 
				transferred during the transition state should th				 be at least as secure as the second policy 
				demands. 
				If FreeS/WAN errs on the side of %hold and lose
				packets, the application layer will compensate.
				
				In some cases (see below) there may be good 
				counter arguments based on ease of use. 
				However, it may be a simple/elegant design 
				to use %hold for all members of this group of
				transitions.

Special Cases
-------------

private		any		Like block->any.
(without conn)

private		private		No action.
(with conn)		
				
		oe-or-clear	Try to rekey.
			 		If success, replace SA.
					If failure, insert clear route.

		clear-or-oe	Send Delete. Keep old conn up for a reasonable
				amount of time (2 minutes?) to avoid "leakage"
				if we can get a connection. If the other side
				does not rekey, fail to clear.

		clear		Clear.

		block		Block.

oe-or-clear	any		Like clear->any.
(without conn)

oe-or-clear	private		Try to rekey.
(with conn)				If success, replace SA.
					If failure, block.

		oe-or-clear	No action.

		clear-or-oe	Like private->clear-or-oe.

		clear		Clear.

		block		Block.

clear-or-oe	any		Like clear->any.
(without conn)

clear-or-oe	private		Try to rekey.	
(with conn)				If success, replace SA.
					If failure, block.

		oe-or-clear	Try to rekey.
					If success, replace SA.
					If failure, treat as clear.

		clear-or-oe	No action. (In this case, we can't easily 
				rekey, and don't need to.)

		clear		Clear.
		
		block		Block.

	
clear		private		Hold packets. Try to key.
					If success, add SA.
					If failure, block.

		oe-or-clear	Option 1: Hold packets. Try to key.
                                        If success, add SA.
                                        If failure, treat as clear.

				Option 2: Send in clear. Try to key.
					If success, add SA.
					If failure, treat as clear.
				1. errs on the side of ease of use, 2. on 
				the side of security.
				I like 1 (until users complain).

		clear-or-oe	Treat as clear until peer initiates.

		clear		No change.

		block		Block.

block		private		Hold packets. Try to key.
                                        If success, add SA.
                                        If failure, block.

                oe-or-clear     Option 1: Hold packets. Try to key.
                                        If success, add SA.
                                        If failure, treat as clear.
				Option 2: Send in clear. Try to key.
					If success, add SA.
					If failure, treat as clear.
				1. errs on the side of ease of use, 2. on 
				the side of security.
				I like 1.
	
		clear-or-oe	Treat as clear until peer initiates.

		clear		Clear.

		block		No change.