Re: [Hipsec] Status of our milestones

Hello,

after having put my major personal roadblock aside, I'd like to get back to RFC5201-bis and get the last issues resolved.

There are still some (few) open issues we need to address. Not all of them can be addressed without any discussion.
Therefore I'd like to ask for some opinions here. All tickets can be found in the ticket system.

I'll start with two of the easier ones:

Ticket 22: R1_COUNTER inclusion in I2
-------------------------------------
http://trac.tools.ietf.org/wg/hip/trac/ticket/22

RFC 5201 makes it optional to echo the R1 counter in the !I2!. However, when its
optional, its hard to implement because you have to account for the case that
the counter is present or missing in the I2. Skipping the counter all together
is not an option because the Initiator uses it to sort out old R1s - so we need
it in the R1. Alternatively, we could leave it out of the !I2! and the Responder
could encode the required generation information into the R1 ECHO_REQUEST. It
would get back the information in any case because the ECHO_RESPONSE in the !I2! is a MUST.
However, we'd have some redundancy with the R1_COUNTER in the R1 then (which we
can't remove because of the reasons stated above). 

My conclusion: I'd make it a MUST. Any comments on this?

Ticket 27: IESG: allow negotiation of KDF
-----------------------------------------
The IESG commented that the key distribution function should be negotiable. We
defined a new and better KDF. Are we done now?  I guess not. We have two
options. Tie the KDF to the Diffie Hellman Group and negotiate it together with
the DH group in the DH group list (my preferred option) OR negotiate it
separately. As I view it, changing the KDF should only happen a) if something
goes horribly wrong and the current KDF becomes insecure or b) if you want to
change the scenario in which you want to apply HIP radically (e.g., if you move
towards embedded systems). I think both cases will not demand high flexibility
in the choice of the KDF (you don't pick another KDF just because you can).
Moreover, we still have plenty of available DH_GROUP IDs left. I would opt for
making the KDF exchangeable but to fix it to the DH group ID. 

Any objections?

I'm looking forward to your feedback.

Tobias

Am 08.08.2011 um 09:55 schrieb Gonzalo Camarillo:

> Folks,
> 
> please, have a look at the dates of our milestones and note that we are
> already a few months behind.
> 
> https://datatracker.ietf.org/wg/hip/charter/
> 
> It's time to put some more energy into the bis drafts.
> 
> With respect to the native NAT traversal draft and the RELOAD instance
> draft, they are waiting for the bis drafts and the RELOAD draft to be
> more mature, respectively. The good news is that the RELOAD draft is
> already being reviewed by the IESG and will likely be published shortly.
> 
> Cheers,
> 
> Gonzalo
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
pgp id: AEECA5BF 