Subject: Re: [Hipsec] Status of WG items

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 13 Sep 2012 11:15:35 +0300

Hi Julien,

if you could respond to Ari's comments on the 5203bis draft below, that
would be great. Also, note that the latest version of this draft has
expired.

Thanks,

Gonzalo

On 27/07/2012 7:22 PM, Ari Keranen wrote:
> Hi Julien,
> 
> On 7/6/12 3:37 AM, Julien Laganier wrote:
>> - 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...
> 
> 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
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2012 08:41:46 -0700

Hi Ari,

On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen <[email-masked]> wrote:
> 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".
>
> 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.
>

These suggestions sound reasonable to me.

--julien

---

From: Ari Keranen <[email-masked]>
Date: Thu, 20 Sep 2012 16:58:47 +0300

Hi Julien,

> These suggestions sound reasonable to me.

OK, great. If you add these to the registration draft, I can update the 
native NAT traversal draft accordingly.

Cheers,
Ari

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Sep 2012 16:49:57 -0700

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

I was going to shamelessly copy/paste section 3.2 of [1] in the
registration draft but I noticed that [1] actually has a normative
dependency on RFC 6253 "Host Identity Protocol Certificates" which is
Experimental. Thus adding the support for certificates to a standard
track HIP registration would cause a so-called downref which could be
problematic...

Gonzalo - what is your take on this?

--julien

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 21 Sep 2012 11:11:43 +0300

Hi Julien,

my take on this is that we need to produce a standards-track document
specifying exactly that. This is what our charter says about it:

https://datatracker.ietf.org/wg/hip/charter/

> o Specify in a standards track RFC how to carry certificates in the
> base exchange. This was removed from the base HIP spec so that the
> mechanism is specified in a stand-alone spec.

Cheers,

Gonzalo

---

From: Julien Laganier <[email-masked]>
Date: Fri, 21 Sep 2012 17:34:57 -0700

Folks,

I've been thinking a bit more about the update of RFC5204 / Rendezvous
Server support. See below:

On Thu, Jul 5, 2012 at 5:37 PM, Julien Laganier <[email-masked]> wrote:
> [...]
> - 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.

I figured two things:

1- relaying an UPDATE packet is pointless in the absence of HIP
mobility support on both endpoints.

2- support for rendezvous server is useful independently of support
for HIP mobility.

Taking both 1. and 2. into account, my conclusion is that it makes
sense to keep the rendezvous server support self-contained in 5203bis,
i.e., without a normative dependency to the mobility support in
5206bis, while 5206 would specify an extension to rendezvous mechanism
for support of relaying UPDATE packets.

Makes sense?

--julien

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 23 Sep 2012 16:25:18 -0700

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
> Sent: Friday, September 21, 2012 5:35 PM
> To: [email-masked]
> Cc: Henderson, Thomas R
> Subject: Re: [Hipsec] Status of WG items
> 
> Folks,
> 
> 2- support for rendezvous server is useful independently of support for
> HIP mobility.
> 

Julien, I would be fine with your proposal.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Mon, 24 Sep 2012 08:32:04 +0800

Hi,

> Julien, I would be fine with your proposal.

seems fine to me as well.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 24 Sep 2012 07:48:08 -0700

Hi Gonzalo, all,

So if we include in the registration a dependency towards the standard
tracks HIP certificates draft (that doesn't exist yet) we would be
tying the two together such that the registration can't be published
before the HIP certificate RFC is.

An alternative would be to move ahead with the current registration
draft without specific dependency on HIP certificates but leaving the
door open for these to be used once they are defined in standard
track; the current draft and RFC already have hooks for authentication
means beyond HIT authentication:

                   In particular,
   REG_FAILED with a failure type of zero indicates the service(s)
   type(s) that require further credentials for registration.

   If the registrar requires further authorization and the requester has
   additional credentials available, the requester SHOULD try to
   register again with the service after the HIP association has been
   established.  The precise means of establishing and verifying
   credentials are beyond the scope of this document and are expected to
   be defined in other documents.

Would that be an appropriate way forward?

--julien

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 Sep 2012 10:26:11 +0300

Hi,

if we have the appropriate hooks in the main specs, we could do as you
suggest. I would be interested in hearing more opinions, though.

Cheers,

Gonzalo