Subject: [Hipsec] Re: Service Definition (Was: question on the hip registration protocol)

From: [email-masked] (Julien Laganier)
Date: Fri Jan 7 05:00:00 2005

Folks,

We were privately discussing the definition of a service in the 
context of the HIP registration: A HIP node (the requester) register 
for a service (such as Rendezvous, or Firewall traversal) at another 
HIP node (the registrar). In the discussion below, we were trying to 
came up with an appropriate definition of service in this specific 
context.

On Friday 07 January 2005 08:06, Pekka Nikander wrote:
>
> Julien Laganier wrote:
>
> > In the terminoly section, we miss the definition of a service; I 
> > propose we use:
> >
> > Service: A facility supplying some public demand (e.g. Firewall
> > traversal, Rendezvous, etc.)
>
> I agree that we seem to need such a definition, but I also think
> that we need to be more careful here.  Basically, we don't want
> all kinds of "services" to be served through the HIP protocol.
> (Or do we?)  That is, at least for the time being, we should
> explicitly limit the services to ones that enhance the capabilities
> of HIP.  Firewall traversal and Rendezvous are good example.
> E-mail notifications or Instant Messaging would be bad examples.

I fully agree with Pekka's opinion; i.e. we don't want all kinds of 
"services" to be served through the HIP protocol. Here's a new 
definition matching your proposal:

Service: A facility supplying enhanced capabilities to the HIP 
protocol (e.g. Firewall traversal, Rendezvous, etc.).

What do you think?

--julien

---

From: [email-masked] (Julien Laganier)
Date: Fri Jan 7 05:16:01 2005

Folks,

Another private discussion we had, dealing with the differences 
between an association and a registration in the context of HIP.

Basically a registration is an association, plus some other state 
related to the service for which the requester has sign-up at the 
registrar. In the firewall traversal case, the registration-specific 
state might be the protocol and port numbers allowed to pass through.

I was wondering if a registration might be a degraded association, 
i.e. it has less state (keying material) or less capabilities (update 
of locators or rekeying).

Your thoughts on the subject are welcomed.

On Friday 07 January 2005 08:15, Pekka Nikander wrote:
>
> > What make a registration different from an association? Is it
> > only the fact that the requester register for some services, i.e.
> > it establish some additional states in the parties involved?
>
> In my opinion, yes.  I think that crux is the additional state.

Ok.

> > Or is the
> > registration a lightweight, soft-state HIP association in which
> > selective parts of the HIP state are thrown away, resulting in an
> > association which has less capabilities (e.g. it can't be
> > rekeyed).
>
> Well, that might be a side effect of *some* services, but IMHO
> that would be orthogonal to the basic registration.  If we
> see that as a component common to many services that rely on
> the registration, most probably we should write another draft
> defining such a mechanism.  However, right now I feel that such
> a thing would be premature.

That's fine with me. So we'd specify that a registration _is_ an 
association _plus_ some state. Then, another specification (e.g. 
Rendezvous) may specify other requirements rendering the registration 
they define something less than a full blown association... 

But such behavior would be registration-type specific and would not be 
specified in the the registration protocol document, like you 
proposed.

> > Here are the excerpts and discussion:
> >
> > -- The management of the registrations requires a REG_REQUEST -
> > REG_RESPONSE exchange over a pair of UPDATE packets --
> >
> > ==> Perhaps "(...) over a pair of UPDATE packets which does not
> > request rekeying of the association"
>
> Well, as ESP is being split out from the base spec, the base spec
> does not even mention rekeying any more.

Ok.

> > -- However, the presence of the registration parameters defined
> > in this specification SHOULD NOT render the usage of the HIP
> > association impossible for other purposes. In other words, the
> > registration parameters enhance the base exchange, but they do
> > not change its basic meaning. --
>
> Well, I still need to think more about this, but my initial
> reaction is that SHOULD NOT sounds like the right level.  But I am
> also open to leaving this unspecified, i.e., removing this piece of
> text out from the draft.
>
> > ==> Perhaps s/SHOULD/MAY/. I have the feeling that some
> > registrations might not maintain a HIP association but only the
> > registration state.
>
> That would make it pretty hard to use UPDATE to renew the state.
> Unless the state is very long lasting (expiration time in days or
> longer), I don't really see any reason why the registrar should
> through out the keying material.

After thinking more about this, I agree with you. SHOULD NOT sounds 
like the appropriate requirement level, and leave the opportunity for 
a future 'service/registration' specification to specify selective 
deletion of parts of the association state, and specific restrictions 
in place.

> > For example, in the rendezvous case, the parties would only
> > retains symmetric integrity keys, and requester HIT and IP
> > address. That would allow a RVS to support more requesters
> > because it does not have to store their public keys.
>
> AFAIK, you don't need to store the public keys to keep up the HIP
> association.  All the messages besides the first few also contain
> the HMAC, which should be sufficient, and verifying the SIG in
> the presence of HMAC is OPTIONAL.  Or isn't it so?  Maybe I have
> missed something?

Ooops, I was talking about the D-H Kij needed to rekey.

Anyway perhaps it's not that important to save a few kBs per 
registration; I have no strong feeling on the question.

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Fri Jan 7 08:26:01 2005

> I am more prone to see registration and association as separate 
> matters.

 From a pure architectural point of view, I agree with you, but I fail 
to get your point.  In practise, in 99% of the cases that I can 
foresee, you need authentication etc. before you can do registration.  
Hence, maybe in 99% of those 99% cases, you most probably want to use a 
registration protocol that is based on the base exchange.

> While the registration specification is about explicit registering, I 
> think it might be wise to consider implicit registering too. That is, 
> not to include it to the registration specification, but not to forget 
> it when defining these terms. I see registration protocol to be only a 
> single path, but not the only one, to establish a registration (state) 
> that is required to deliver service(s) for a HIP host.

What's the news here?  Even if you have the world's best hammer, it is 
still sometimes better to use a screwdriver, isn't it?  The fact that 
you *standardize* A doesn't mean that you can't use B.  (Here I must 
admit that I've seen people claiming that if A is a standard you can't 
use B, but I consider such claims utterly silly.  And then, market 
dynamics is a third matter, still separate from what is standardised 
and what can or cannot be used.)

--Pekka

---

From: [email-masked] (Teemu Koponen)
Date: Fri Jan 7 09:02:00 2005

On Jan 7, 2005, at 15:25, Pekka Nikander wrote:

> Hence, maybe in 99% of those 99% cases, you most probably want to use 
> a registration protocol that is based on the base exchange.

I was too inaccurate it seems, as I do fully agree with you (and 
Hannes) about using a base exchange based registration protocol.

I was merely (over-) emphasizing that the additional state spanning 
over requester, (registrar,) *and* service is something that may also 
emerge by other means, which is of course out of context from the HIP 
registration protocol point of view. So, it was just a little nuance 
that the plus sign Julien used raised within me.

Teemu

--

---

From: [email-masked] (Teemu Koponen)
Date: Fri Jan 7 09:04:01 2005

I am more prone to see registration and association as separate 
matters. While the registration specification is about explicit 
registering, I think it might be wise to consider implicit registering 
too. That is, not to include it to the registration specification, but 
not to forget it when defining these terms. I see registration protocol 
to be only a single path, but not the only one, to establish a 
registration (state) that is required to deliver service(s) for a HIP 
host.

Teemu

--