Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)

[Robert Moskowitz <[e-mail]>]

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.
> Yes.
>
>> 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 immediately.
>
> 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.
>>
>> Bob
>>
>> _______________________________________________
>> Hipsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hipsec
>
>