Subject: [Hipsec] RE: Registration vs. Association (Was: question on the hip regist ration protocol)

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

hi julien, 

thanks for raising this issue. please see my comment below:

> 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).

there are two types of state established with a registration (or association
protocol):

- security related state:
this is state established with the "modified" hip protocol (minus ipsec sa
establishment). 
basically it contains of information negotiated with the HIP_TRANSFORM and
keying material. 
there is no reason why this should have a "lower" quality than in the base
hip protocol. 

- state related to the "service":
you are right that in case of firewall signaling this will be information
related to source/destination ip address and spi (if you want to allow ipsec
protected data traffic to traverse). 

a separate question is regarding the usage of certain features of the
registreation protocol. i think that it would be good to reuse the
capabilities of the base protocol and extensions (e.g., multi-homing and
mobility). 

ciao
hannes

> 
> 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
>