Subject: [Hipsec] review of draft-ietf-hip-registration-00.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Oct 2005 20:23:46 +0300

Julien et al,

I have read your draft. Overall, this draft is in VERY good
shape for a -00 and probably ready for last call. I did have
some comments, however:

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

Hm. Are these "further credentials" defined somewhere?
Would these be other certs, some userids (e.g. NAI) without
security, or some additional authentication schemes, perhaps
modelled after IKEv2's EAP mode?

Also, I fear that this might lead us on a path where we
start having a need to prove what was services were
advertised, requested, and granted.

Don't get me wrong, I would love this type of functionality.
Just making a point that it may be harder than just "providing
additional credentials".

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             Type              |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Min Lifetime  | Max Lifetime  |  Reg Type #1  |  Reg Type #2  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Reg Type #3  |                                               |
>    +-+-+-+-+-+-+-+-+                 Padding                       +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is there a provision for including parameters of some sort in the
registration types. For instance, "I support RVS for the foobar domain".
(Not sure if this is such a great example, but I'm pretty sure there
will be services that go beyond "I do service X".) The same issue
may appear for REG_REQUEST and REG_RESPONSE.

This would complicate the packet, however.

Editorial:

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             Type              |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Min Lifetime  | Max Lifetime  |  Reg Type #1  |  Reg Type #2  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Reg Type #3  |                                               |
>    +-+-+-+-+-+-+-+-+                 Padding                       +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think you mean Reg Type #1 ... Reg Type #n?

--Jari

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 16 Oct 2005 10:35:21 +0200

Jari,

Extensibility, or allowing new parameters to be attached
to any given registration type in REG_INFO, REG_REQUEST,
REG_RESPONSE, and REG_FAILED, was an explicit goal, IIRC.
If the draft doesn't say that, such a statement should
be added.   A new subsection to Section 3 and something
to Section 5, perhaps?  (Unfortunately I don't have time
now to propose text, sorry.)

What comes to credentials, I think the best way forward
is to explicitly say that establishing more credentials
is beyond the scope of this spec and expected to be
specified elsewhere.  What do you think?

--Pekka

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Oct 2005 12:38:31 +0300

Pekka,

> to Section 5, perhaps?

Works for me. And, of course, I may have missed a statement
if it already was included there.

> specified elsewhere.  What do you think?

I think this is best.

--Jari

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Oct 2005 13:34:39 +0200

> if it already was included there.

FWIW a previous version of the rendezvous I-D used that extensibility 
feature to allow registration with different flavors of the 
rendezvous service (i.e. header rewriting vs tunneling.) 

I went through the current registration I-D and this extensibility 
feature is mentionned in Section 5, "Establishing and Maintaining 
Registrations":

   Establishing and/or maintaining a registration may require 
   additional information not available in the transmitted
   REG_REQUEST or REG_RESPONSE parameters.  Therefore, registration
   type definitions MAY define dependencies for HIP parameters that
   are not defined in this document.  Their semantics are subject to
   the specific registration type specifications.

Is it sufficient, or should we add the following sentence in Section 
3, "HIP Registration Extension Overview",  between "...to register 
with the service." and  "The following sections describe...":

    Both the registrar and the requester MAY also include in the
    messages exchanged additional HIP parameters specific to the
    registration type implicated.  Other documents will define which
    and how these parameters shall be used.

> > specified elsewhere.  What do you think?

Works for me. I suggest that we complete, in Section 3.3 "Registrar 
Granting or Refusing Service(s) Registration", the paragraphs:

   (...) 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 again register with the service after the HIP
   association has been established.

With the sentence:

   The precise means of establishing and verifying credentials are
   beyond the scope of this document and are expected to be defined
   in other documents.

Thoughts?

--julien

---

From: Lars Eggert <[email-masked]>
Date: Mon, 17 Oct 2005 14:45:33 +0200

Both changes sound good to me.

Lars

PS: Thanks for the review, Jari!
--
Lars Eggert                                     NEC Network Laboratories