Subject: [Hipsec] RE: Registration vs. Association

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 7 Jan 2005 11:43:37 +0100

hi,

i don't quite understand the difference between registration and
association. 
it might only be a terminology issue but what we need is: 

* a protocol that allows an entity a to communicate with an entity b to 
  - authenticate/authorize each other
  - establish a security association (not an ipsec sa) - "only" keying
material & algorithms
  the protocol should provide some basic security features, such as dos
protection. 
  obviously the protocol should be "lighweight". 

* only creating registration protocol specific state is fun (to protect
signaling messages between entity a and entity b) but there will typically
be a little bit more about it. in the rvs draft you describe the additional
pieces that are required for rvs to work. for middleboxes the information
will again be different and for hi3 it will be different again. 

from this point of view i think it would be good to keep the registration
protocol simple and generic. it seems to be useful in some scenarios.

the fact that we want to reuse the hip protocol as a registration protocol
(and an existing protocol in general) makes the description fairly short.
this is also good. there are certainly other candidates as well but i
personally prefer hip. 

ciao
hannes

> -----Original Message-----
> From: Teemu Koponen [mailto:[email-masked]] 
> Sent: Freitag, 07. Jänner 2005 11:32
> To: Julien Laganier
> Cc: Tschofenig Hannes; Pekka Nikander; Andrei Gurtov; 
> [email-masked]
> Subject: Re: Registration vs. Association
> 
> On Jan 7, 2005, at 12:17, Julien Laganier wrote:
> 
> >> 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.
> 
> 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
> 
> --
> 
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec