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
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
