Re: [Hipsec] HIP Registration Extension

[Julien Laganier <[e-mail]>]

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 
registration (sending


>>> ...
>>
>> 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?
> 
>>> ... but nothing is said about multiple REG_INFOs in the draft.
>>
>> Thus an additional specification would be required it seems.
> 
> Yes.
> 
>>>  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. 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."
> 
>> Do you think more text is needed?
> 
> Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max 
> Lifetime" / "Lifetime" values.
> 
> -Lauri

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