Re: [Hipsec] HIP Registration Extension

[Lauri Silvennoinen <[e-mail]>]

On Mon, 18 Aug 2008, Julien Laganier wrote:

Hi Julien,

> Hi Lauri,
> Some comments inlined below:
>
>> ...
>
> 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.

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