On 09/19/2016 06:19 AM, Tom Henderson wrote:
Bob, sorry for the delay in replying (inline below)

On 09/13/2016 02:14 AM, Robert Moskowitz wrote:
I have one question on sec 5.4 before I enter a comment...

On 09/12/2016 03:28 PM, Mirja Kuehlewind wrote:
5) section 5.4: How long will an address be in UNVERIFIED state in case
the verification is not successful (no reply). Is there a timer? How
often will the peer retry the verification test? How long does the peer
wait until resending the verification packet?

It took me a couple readings of 5.4 to THINK I understand fig 7.

I THINK this occurs after Mobile Host has sent its HIP UPDATE with the
new locator information.

I believe the implication of this figure is that the stationary node
(peer host) sends its address validation HIP UPDATE and instead of
receiving the HIP UPDATE with ACK, it receives actual data which it may
interpret as the ACK.
Yes, actual data that implies that the mobile host received its previous 
message at the new address.

So I have two points.

First does this only apply when there are new SPI?  What about a move
with no SPI changes?
I think the original intent may have been to cover the case where the UPDATE 
with ACK (the third leg of the handshake) was lost or slow to return, and that 
data plane may be faster at picking up the address change and using it 

However, I am not seeing the scenario with a new SA where there is not a third 
UPDATE, as in:

   Mobile             Peer
1)        --UPDATE ->
2)        <--UPDATE-
3)        --UPDATE ->

If message 2) has "NEW SPI in ESP_INFO (UPDATE)", then it will need a SEQ and a 
retransmission timer to protect it, until the packet 3) arrives with the ACK.

In a move with no SPI changes, the draft says that a nonce like an ECHO_REQUEST 
should be exchanged (Figure 3).
Second, the actual figure should include the original HIP UPDATE from
Mobile Host to make it clear the nature of the mobility.
OK, I agree.

I would be inclined to modify it something along the lines below.

     Mobile host                                   Peer host

                     ESP_INFO, LOCATOR_SET (UPDATE)

                                                    prepare incoming SA
                       NEW SPI in ESP_INFO (UPDATE)
    switch to new outgoing SA
                            data on new SA
                                                    mark address ACTIVE

                     ACk (UPDATE) (later arrives)

              Figure 7: Address Activation Via Use of a New SA

This is much better.   Thanks

Sorry for the late review of this draft.

I can submit an official comment if others think my questions raise
clarity issues.


Hipsec mailing list

Hipsec mailing list

Reply via email to