Subject: Re: [Hipsec] Status of WG items

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jul 2012 17:37:34 -0700

Hi everyone,

Sorry for the delay.

Here's an update from my side:

- 4843bis (ORCHIDv2) is ready for WGLC as soon as I incorporate the
update ORCHIDv2 generation algorithm. I will do this ASAP
- 5203bis (registration) can IMHO be republished as is as I haven't
seen any issue with the original version. If people agree I could
republish it and we could WGLC it...
- 5204bis (rendezvous) needs one more subsection regarding relaying of
the UPDATE packet to support double jump of mobile nodes. As this
isn't really useful without the mobility support my proposal is to
tackle this one together with the 5206bis.
-5205bis (DNS support) lacks a DNS RR format for ECC support as per
5201bis, and we also need to make sure the new ORCHIDv2 support has no
implications on the DNS RR format. Work in progress...

Comments?

--julien

On Tue, Jun 26, 2012 at 1:15 PM, Tobias Heer <[email-masked]> wrote:
> Hi,
>
> Am 26.06.2012 20:06, schrieb Henderson, Thomas R:
>
>> Gonzalo,
>>
>> I'm the editor of 5206-bis (mobility), which recently expired.  There are
>> 13 issues in the tracker, and I've been letting them sit for now in an
>> effort to get the first batch of WG documents ready for WGLC (namely, 4423,
>> 4843, 5201, and 5202).  I'll turn my attention back to 5206-bis open issues
>> once we get at least 4843, 5201, and 5202 done.
>>
>> I'm also a co-author on 5201-bis.  We have only three open issues on that
>> draft, one of which is to align 4843-bis with 5201-bis, and the other two
>> pertaining to some cryptography issues that seem close to being resolved.  I
>> will post some suggested text to the list for these two items.
>>
> I agree with Tom. Only few issues remain for 5201-bis. All comments from the
> reviewers have been adressed and we are really close to finalizing the
> document.
>
> What remains open are the changes to the ORCHID document. Without these
> changes, 5201-bis is incomplete. However, these are minor changes and Julien
> already suggested text on the list. Therefore, I believe he can do these
> changes quickly.
>
> Tobias
>
>
>> I believe that we are close now to being able to request a WGLC on 4843,
>> 5201, and 5202 bis documents, and I'd like to see that happen before the
>> Vancouver meeting.
>>
>> - Tom
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Gonzalo Camarillo
>>> Sent: Tuesday, June 26, 2012 1:15 AM
>>> To: HIP
>>> Subject: [Hipsec] Status of WG items
>>>
>>> Folks,
>>>
>>> the list has been relatively quiet lately and the energy within this WG
>>> has also been quite low in general in the last months. Could the
>>> editors of all our WG items please let this mailing list know what the
>>> status of each document is and what the next steps are?
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>> _______________________________________________
>>> Hipsec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hipsec
>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 9 Jul 2012 09:10:39 -0700

> Behalf Of Julien Laganier
> Sent: Thursday, July 05, 2012 5:38 PM
> To: Tobias Heer
> Cc: [email-masked]; Julien Laganier
> Subject: Re: [Hipsec] Status of WG items
> 
> Hi everyone,
> 
> Sorry for the delay.
> 

I had a read of this document and agree with your suggestion to move it forward with this initial set (as it provides no technical changes from RFC 5203).

> the UPDATE packet to support double jump of mobile nodes. As this isn't
> really useful without the mobility support my proposal is to tackle
> this one together with the 5206bis.

+1.  I'll post a refresh of 5206bis before the meeting cutoff.  A refresh of 5204bis (as well as 5205bis) would also be appropriate.

- Tom

---

From: Ari Keranen <[email-masked]>
Date: Fri, 27 Jul 2012 19:22:51 +0300

Hi Julien,

> republish it and we could WGLC it...

I posted some comments about 5203bis earlier this year but back then 
there was no discussion regarding them. So, here goes again.

Some of these have been discussed also earlier on this list (these 
relate to requirements discovered with the native NAT traversal draft 
[1]), but I'll have them all here for easier reference.

Currently, the registrar has no way of indicating that it would 
otherwise accept the registration, but it's currently running low on 
resources. For this purpose, a failure type "Insufficient resources" 
could be added to the "registration failure types".

Registration using authentication with certificates could be part of the 
registration RFC. Currently, only authentication with HI is defined, but 
knowing all HIs beforehand is not practical in many cases.

Text in section 3.2. of [1] could be used as a basis for this (just 
replace "HIP' data relay" with "registrar"). Also, if this 
authentication mode is added to the draft, failure type "Invalid 
certificate" should be added for the failure case.

Should we have these in the registration draft?

Cheers,
Ari

[1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 27 Jul 2012 15:04:01 -0400

On 07/27/2012 12:22 PM, Ari Keranen wrote:
> Registration using authentication with certificates could be part of 
> the registration RFC. Currently, only authentication with HI is 
> defined, but knowing all HIs beforehand is not practical in many cases.
>

These are all reasonable. I am more and more looking at HIT 
authentication services, but I know the value of certificates in 
processes like this, though I keep taking a look at things like ECQV 
certs as an alternative to X.509 certs...

---

From: Ari Keranen <[email-masked]>
Date: Tue, 31 Jul 2012 09:13:40 -0700

> certs as an alternative to X.509 certs...

Thanks Bob. Frankly, I'm not a big fan of X.509 certs either, so 
something else would work for me too. Anyway, something more than "just 
knowing HIs" would be useful.

Cheers,
Ari