Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis

[Robert Moskowitz]

On 09/26/2016 09:08 AM, Miika Komu wrote:

Hi,

On 09/16/2016 02:45 PM, Robert Moskowitz wrote:



On 09/16/2016 06:57 AM, Tom Henderson wrote:




On Thu, 15 Sep 2016, Robert Moskowitz wrote:


5206-bis specifies how to user RVS for the 'double-jump' mobility
problem.

3.2.3 1) says:

1. The mobile host sending an UPDATE to the peer, and not receiving
an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the
peer, if such a server is known.

But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC
parameters and it had created a VIA_RVS parameter to send in the R1.


Yes, but the responder may not know the initiator's RVS even if the
the responder's RVS was used, and it also may be the case that neither
host's RVS was involved in the session setup.


I see now.  As currently speced, R has no way of learning I's RVS. The
'easy' way to fix this is for I to include a VIA_RVS in the I2 packet
for mobility support.

"If you every want to get back to me, I can always be reached at this
number".


do you actually need the initiator's RVS for double jump? I think the 
responder's RVS is enough.


Then the Initiator's UPDATE must be successful before the Responder can 
perform its UPDATE successfully.  This way they can operate in parallel.






This VIA_RVS provides the knowledge and locator of the peer's RVS.

In fact an aggressive mobility UPDATE would be sent simultaneously to
the host and its RVS.  If the host had not moved itself, it gets both
and drops the one from the RVS.


I believe that Baris Boyvat on the InfraHIP project was looking a
while back at such an approach to fast mobility; it was called
'shotgun' approach to mobility and multihoming (try all candidates
simultaneously), if I remember correctly.


Yes, the idea was to send I1 (or UPDATE) through all the available 
address pairs, but I think the idea is now achieved in a more 
controlled way in draft-ietf-hip-native-nat-traversal-13


I will look at that.  But what if there is no NATs to traverse? That 
there are 2+ interfaces, all native IPv6?


But I will review nat-traversal.

thanks

Bob

___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi René,

On 09/11/2016 11:06 PM, René Hummen wrote:

Hello Miika,

going through your email again, I saw a total of four suggestions.

Three of them refer to imprecisions in the text of RFC 7401 (which I
copy/pasted for HIP DEX). There, I understood that consistency with RFC
7401 has a higher priority than only fixing your comments for HIP DEX,
but keeping the text as is for RFC 7401. This means, I will not modify
the text in the HIP DEX draft. Is this also your intention?


yes, 7401 takes precedence over my comments.


The last remaining issue is related to the UPDATE message and the
rekeying procedure (Section 6.10.). Here, I added the following
paragraph for clarification purposes:

   [RFC7402] specifies the rekeying of an existing HIP SA using the
   UPDATE message.  This rekeying procedure can also be used with HIP
   DEX.  However, where rekeying involves a new Diffie-Hellman key
   exchange, HIP DEX peers MUST establish a new connection in order to
   create a new Pair-wise Key SA due to the use of static ECDH key-pairs
   with HIP DEX.

Does this fix your issue?


Yes. I assume you mean a new HIP association with connection.


BR
René



On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu > wrote:

Hi,

On 06/03/2016 02:20 PM, René Hummen wrote:

This is part 3 of 3.


I am fine with your fixes. Some comments below.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu

>> wrote:

> [...]

 > 6.2.1.  CMAC Calculation
 >
 > [...]
 >
 >
 > 5.  Set Checksum and Header Length fields in the HIP
header to
 > original values.  Note that the Checksum and Length fields
 > contain incorrect values after this step.

I guess also the values following HIP_MAC should be restored
since
they were wiped in the step 2.


I also found this description a bit imprecise, but it is taken from
RFC7401. Step 2 already hints at the fact that parameters following
HIP_MAC may still be of interest:
"Remove the HIP_MAC parameter, as well as all other parameters
that follow it with greater Type value, saving the
contents if
they will be needed later."

The question is whether we want to fix the description for HIP
DEX or to
keep things as they are for consistency reasons. In the former
case, I
would prefer to completely rewrite the verification procedure to
work on
the received packet without removing any parameters. However, we
should
then probably also post an errata to RFC7401. If there are no stong
opinions about that, I would go for the latter option.


Latter option works for me too.

 > The CKDF-Extract function is the following operation:
 >
 > CKDF-Extract(I, IKM, info) -> PRK

What does the arrow operator signify? I thought that it
produces PRK,
but PRK is actually defined below.


The arrow is part of a basic mathematical function definition.
So yes,
PRK is the output (domain), but we still need to give it a
proper name.
I changed the artwork to clearly point out the inputs and outputs.


Thanks, it is now better.

Please check this section again in the updated version and get
back to
me if the above changes do not sufficiently help your understanding.


It is good now, thanks!

 > Llength of output keying material in octets
 >  (<= 255*RHASH_len/8)
 > |denotes the concatenation
 >
 > The output keying material OKM is calculated as follows:
 >
 > N   =  ceil(L/RHASH_len/8)
 > T   =  T(1) | T(2) | T(3) | ... | T(N)
 > OKM =  first L octets of T
 >
 > where
 >
 > T(0) = empty string (zero length)
 > T(1) = CMAC(PRK, T(0) | info | 0x01)
 > T(2) = CMAC(PRK, T(1) | info | 0x02)
 > T(3) = CMAC(PRK, T(2) | info | 0x03)
 > ...

The Expand was a bit more clear, but still didn't understand
how to
get to the
Expanded key material due the arrow notation.


Ok, let's clarify this as several comments are related to the arrow
notation. For the function definition we use the mathematical arrow
notation (same as RFC 5869) and for the actual opertation we use the
equals sign (same as RFC 5869). In the end, they denote the same
thing:
"assign X to Y".


Ok, this is 

Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis

[Miika Komu]

Hi,

On 09/16/2016 02:45 PM, Robert Moskowitz wrote:



On 09/16/2016 06:57 AM, Tom Henderson wrote:




On Thu, 15 Sep 2016, Robert Moskowitz wrote:


5206-bis specifies how to user RVS for the 'double-jump' mobility
problem.

3.2.3 1) says:

1. The mobile host sending an UPDATE to the peer, and not receiving
an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the
peer, if such a server is known.

But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC
parameters and it had created a VIA_RVS parameter to send in the R1.


Yes, but the responder may not know the initiator's RVS even if the
the responder's RVS was used, and it also may be the case that neither
host's RVS was involved in the session setup.


I see now.  As currently speced, R has no way of learning I's RVS. The
'easy' way to fix this is for I to include a VIA_RVS in the I2 packet
for mobility support.

"If you every want to get back to me, I can always be reached at this
number".


do you actually need the initiator's RVS for double jump? I think the 
responder's RVS is enough.



This VIA_RVS provides the knowledge and locator of the peer's RVS.

In fact an aggressive mobility UPDATE would be sent simultaneously to
the host and its RVS.  If the host had not moved itself, it gets both
and drops the one from the RVS.


I believe that Baris Boyvat on the InfraHIP project was looking a
while back at such an approach to fast mobility; it was called
'shotgun' approach to mobility and multihoming (try all candidates
simultaneously), if I remember correctly.


Yes, the idea was to send I1 (or UPDATE) through all the available 
address pairs, but I think the idea is now achieved in a more controlled 
way in draft-ietf-hip-native-nat-traversal-13




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec