Subject: [Hipsec] RE: Registration vs. Association

From: [email-masked] (Tschofenig Hannes)
Date: Fri Jan 7 05:44:01 2005

hi,

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

* 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.=20
  obviously the protocol should be "lighweight".=20

* 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.=20

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.=20

ciao
hannes

> -----Original Message-----
> From: Teemu Koponen [mailto:[email-masked]]=20
> Sent: Freitag, 07. J=E4nner 2005 11:32
> To: Julien Laganier
> Cc: Tschofenig Hannes; Pekka Nikander; Andrei Gurtov;=20
> [email-masked]
> Subject: Re: Registration vs. Association
>=20
> On Jan 7, 2005, at 12:17, Julien Laganier wrote:
>=20
> >> Well, that might be a side effect of *some* services, but=20
> IMHO that=20
> >> would be orthogonal to the basic registration.  If we see=20
> that as a=20
> >> component common to many services that rely on the=20
> registration, most=20
> >> 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=20
> > association _plus_ some state. Then, another specification (e.g.
> > Rendezvous) may specify other requirements rendering the=20
> registration=20
> > they define something less than a full blown association...
> >
> > But such behavior would be registration-type specific and=20
> would not be=20
> > specified in the the registration protocol document, like you=20
> > proposed.
>=20
> I am more prone to see registration and association as=20
> separate matters. While the registration specification is=20
> about explicit registering, I think it might be wise to=20
> consider implicit registering too. That is, not to include it=20
> to the registration specification, but not to forget it when=20
> defining these terms. I see registration protocol to be only=20
> a single path, but not the only one, to establish a=20
> registration (state) that is required to deliver service(s)=20
> for a HIP host.
>=20
> Teemu
>=20
> --
>=20