Re: [Hipsec] HIP Registration Extension

[Julien Laganier <[e-mail]>]

[sorry for resent, wronly hit CTRL+ENTER]

Hi Lauri,

Some more thougths...

Lauri Silvennoinen wrote:
> On Mon, 18 Aug 2008, Julien Laganier wrote:
>>
>> Ok for the usecase, but shouldn't this be considered as an error from 
>> the MN. The MN implementation supposedly knows that RVS and ICE are 
>> exclusive, and shouldn't try to register for both at the same time on 
>> the same node.
> 
> It can and should be considered as an error from the Requester. However, 
> this does not mean that the Requester cannot send such a message. I'm 
> mostly concerned about the server implementation in all of the issues. 
> Thus the question is: how does the server respond to a registration 
> attempt having services that cannot co-exist. RFC 5203 does not provide 
> instructions for this. Are you suggesting that the server should just 
> silently drop such a request? If so, this should be put in clear text 
> into the RFC.

I think since the RFC allows the server to cancel the earlier 
(incompatible) registration, then it should do that, and grant the new one:

    A registrar (and an attached service) MAY cancel a
    registration before it expires, at its own discretion.  However, if
    it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all
    registered requesters.

>>> ...
>>
>> In that case, wouldn't be needed to signal to the MN which types of 
>> registration have to be canceled for the requested one to be granted?
>>
> 
> This would be even better, but then we would need individual Failure Types
> for each registration that needs to be cancelled. So instead of
> 
>     Failure Type    Reason
>     ------------    --------------------------------------------
>     2               Cancellation required
> 
> we would have for example:
> 
>     Failure Type    Reason
>     ------------    --------------------------------------------
>     101             RVS Cancellation required
>     102             HIP RELAY Cancellation required
>     103             ...
>     ...
> This could get too complicated when the number of HIP services (and HIP 
> service related specifications) increases. So I would stick to the 
> single "Cancellation required" value instead and let it be local policy 
> at the Requester to know which services cannot co-exist. Either way, 
> isn't it better to signal "Cancellation required" than "Registration 
> requires additional credentials" or "Registration type unavailable" (or 
> to remain silent) in this case?

Defining new failure types wouldn't be good. I was thinking more about 
piggybacking to the REG_FAILED for "cancellation required" with a 
REG_TYPES_TO_CANCEL parameter containing the registrations types that 
shall be cancelled before the requested registration is granted. But 
that seems to complex. Since this is somehow an error case from the 
requester I think we should do as I suggested earlier, i.e. the 
registrar signal that incompatible registations were cancelled, and 
accpet the new one.

>>> ... but nothing is said about multiple REG_INFOs in the draft.
>>
>> Thus an additional specification would be required it seems.
> 
> Yes.

I am not sure it is required to indicate different lifetimes for 
different services though. If you really want to handle various 
lifetime, you can get the same result by announcing the min lifetime of 
services you're offering for all services.

>>>  2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters 
>>> that
>>>     have redundant services? These parameters are of the following form:
>>> ...
>>
>> I consider this as broken behavior from the registrar side, but anyway 
>> it seems the MN could simply ignore duplicates Reg types with no harm.
> 
> Broken behavior yes, but again, the RFC does not state in clear text how 
> to handle such a case. If a REG_REQUEST has redundant services, then 
> it's broken behavior at the Requester side. If a REG_RESPONSE or a 
> REG_FAILED has redundant services, then it's broken behavior at the 
> Registrar side. I suggest the following:
> 
> The REG_REQUEST case i.e. the client has requested redundant services. 
> The server should not allow any broken behavior from the client. 
> Therefore the whole packet having redundant services should be just 
> silently dropped. 

I disagree. If we follow the "be conservative in what you send, liberal 
in what you accept", a peer receiving duplicate registration types 
should just ignore the duplicated occurrences.

> Note that the process of handling the REG_REQUEST 
> parameter at the server involves the creation of some kind of 
> registration state and that this creation can be time and resource 
> consuming.
> 
> The REG_RESPONSE and REG_FAILED cases i.e. the server has granted/denied 
> redundant services. This should be a local policy issue at the client. 
> If the server shows broken behavior, the client can always choose to use 
> another server.
> 
>>>  3) What happens if registration cancellation does not succeed? In 
>>> Section
>>>     5 it is said:
>>> ...
>>
>> Again that would be broken behavior from the registrar side, we have a 
>> SHOULD there. If it doesn't do so, then it either doesn't reply or 
>> send REG_FAILED, in any case the MN would not be be mistaken in 
>> believing the cancellation was successful.
> 
> Perhaps this could be clarified by saying "The Requester cannot assume 
> that the cancellation was successful until it receives a REG_RESPONSE 
> with a zero lifetime."

I think this is implicit in the specification, don't you think so?

>> Do you think more text is needed?
> 
> Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max 
> Lifetime" / "Lifetime" values.

As I said, not sure that's really needed for any usecase. And in case 
you really have a hard requirement to support that, you could configure 
different Registrars announcing different lifetimes w/ different HITs on 
the same node. That can be left to implementation.

--julien
_______________________________________________
Hipsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hipsec