RE: [Hipsec] a state machine proposal for mm-03

["Henderson, Thomas R" <[e-mail]>]

Miika, I am catching up on this email, and I will respond inline below,
trying to consider the other exchanges you've had with Pekka. 

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Monday, April 03, 2006 8:54 AM
> To: [e-mail]
> Subject: [Hipsec] a state machine proposal for mm-03
> 
> Simplified State Machine without Peer Initiated Rekeying
> ========================================================
> 
> Note1: since there are no other HIP header types for mobility and
> multihoming (other than UPDATE), the actual packet processing depends
> on the parameters in the HIP packet.
> 

Agreed.

> Note2: the state machine is simpler to design if we leave out the peer
> initiated rekeying (section 3.2.1.2 in the draft). This way, we can
> assume that the UPDATE exchange consists of three packets and that
> each packet can be distinguished from each other by the precence of
> LOCATOR, ECHO_REQUEST or ECHO_RESPONSE.

I agree that this scenario can be eliminated from the overview section,
since it may not frequently occur in practice, but I don't know whether
we want to strictly forbid it.

I also think that you should avoid treating these parameters as
surrogates for a pseudo-mobility HIP type (i.e., LOCATOR == mobile I1,
ECHO_REQUEST == mobile R1, etc.).  

LOCATOR is just sent to the peer based on local mobility/policy
decision, and the UPDATE is ACKed for reliability's sake.
ECHO_REQUEST/RESPONSE is a nonce exchange, used by the peer for
reachability test.  We describe some scenarios where these parameters
can be piggybacked on the same UPDATE message, but there is no
requirement to do so, and I would prefer not to constrain it in that
way.  For instance, we should not require that the peer send the
ECHO_REQUEST, nor should we require that the ACK of the LOCATOR also
contain an ECHO_REQUEST rather than be in a separate packet.

I am agreeing with Pekka's point on decoupling, in general.

> 
> Note3: reusing the same state variables on both hosts. At the mobile
> host (the sender of LOCATOR) it is related to the data structures of
> the source IP. On the corresponding node (receiver of LOCATOR), it is
> related to the destination IP.
> 

I agree with Pekka-- I do not see requirement for this and think that it
may actually be constraining.

> Note4: need some fresh eyes to verify that this is actually 
> sensible :)
> 
> Send UPDATE with LOCATOR:
>   - Triggered at the MN depending on changes in network attachments
>     and according to local policies
>   - Removed addresses are DEPRACATED (and not included in the
>     LOCATOR)
>   - All other addresses are UNVERIFIED (and included in the LOCATOR)
>   - Set preferred LOCATOR depending on local policies
>   - Send UPDATE with LOCATOR for the CN

I disagree with your proposal to try to guess what states the peer will
assign to the different addresses-- I do not see the requirement to do
it this way.

> 
> Receive HIP UPDATE:
> - Verify the HIP packet: HMAC, SIG, the presence, dependencies and
>   validity of the parameters.
>   - If the result is failure, goto DROP.
>   - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or
>     ECHO_RESPONSE (only one of them can be contained in the packet)
> 
as stated above, disagree that only one parameter type can be contained
in these messages 

> Received LOCATOR:
> - For each MN address in the received LOCATOR
>   - State is DEPRACATED or UNKNOWN
>     - Goto UNVERIFIED and send ECHO_REQUEST

sending ECHO_REQUEST is based on local policy decision and shouldn't be
automatic.  There may be lots of announced addresses that the receiver
may not care about checking immediately.

Also, DEPRECATED to UNVERIFIED state change requires peer to send a new
lifetime to a DEPRECATED address.  Your description does not have the
notion of locator lifetimes.

>   - State is UNVERIFIED
>     - Resend ECHO_REQUEST and decrease retransmission timeout

(same comment about sending the nonce applies).  I do not understand
about decreasing (rather than increasing) timeout.  Shouldn't possibly
the retransmissions for the address check be decoupled from receiving a
new LOCATOR?

>   - Any other state, DROP

There may be addresses in ACTIVE state that are not changed-- I think
you want to add "- State is ACTIVE and address hasn't changed (do
nothing)"

You also should mention that any address *not* in LOCATOR is DEPRECATED
immediately.  

> 
> Received ECHO REQUEST:
> - For each MN address in the corresponding LOCATOR
>   - State is UNVERIFIED
>     - Goto ACTIVE and send ECHO_RESPONSE
>   - Any other state, DROP

this again seems to be an instance of trying to mirror state variables,
which I disagree with, and Pekka seems to have objected to also.  I
would rather describe it as "Received ECHO_REQUEST, send ECHO_RESPONSE"
and leave it at that.

> 
> Received ECHO_RESPONSE:
> - Goto DEPRACATED for all old addresses not present in LOCATOR

This step is done upon receiving LOCATOR-- see above.

> - For each MN address in the corresponding LOCATOR
>   - State is UNVERIFIED
>     - Otherwise goto ACTIVE
>     - Change preferred LOCATOR when necessary
>   - Any other state, DROP

Would rephrase the above as " - Move the address whose reachability was
confirmed by the ECHO_RESPONSE from UNVERIFIED to ACTIVE; do not change
any other states"

> > > Receive ESP:
> > > - For the ESP address
> > >   - State is UNVERIFIED
> > >     - Verify ESP validity. Goto DROP if failed
> > >     - Change preferred LOCATOR when necessary
> >
> > Did we specify this?  May make sense sometimes, but again,
> > beware....  ESP doesn't protect IP source...
> 
> This was the CBA optimization. Maybe it should be mentioned 
> explicitly.

I think that what is being referred to here is that a successful
decryption of ESP on a new SPI is itself a reachability check, as
discussed in paragraph four of Section 5.4.  This is an optional
optimization.

>     - Process ESP if there are credits left, and decrease credits.
>     - Otherwise DROP

I think you want to increase credits?  Or are you trying to mirror the
peer's credit variable (which I wouldn't understand)?

>   - State is ACTIVE
>     - Process ESP
>   - Any other state, DROP
> 
> Send ESP:
>   - Increase credits

(decrease credits?)  Actually, decrease only if in UNVERIFIED state;
otherwise, no-op.

> 
> UPDATE retransmission timeout for LOCATOR (at MN):
>   - State is UNVERIFIED
>     - Resend and decrease retransmission counter
>   - Any other state
>     - DROP and zero retransmission counter
> 

again, address states are not relevant here.

> UPDATE retransmission timeout for ECHO_REQUEST (at CN):
>   - State is UNVERIFIED
>     - Resend and decrease retransmission counter
>   - Any other state
>     - DROP and zero retransmission counter

I would assume that UPDATE is trying to confirm an UNVERIFIED address,
and that if the UPDATE is overcome-by-events (OBE), this timer would
have been cancelled.

> 
> UPDATE retransmission timeout for ECHO_RESPONSE (occurs at 
> the MN when no
> ESP was received from the CN from a new address?):
>   - State is ACTIVE
>     - Resend and decrease retransmission counter
>   - Any other state
>     - DROP and zero retransmission counter

this can just be handled by normal UPDATE mechanisms

> 
> Handling of CLOSE with ESP_INFO:
> - TBD

The other opinions seemed to be to not use CLOSE for this purpose.

Tom

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec