Re: [Hipsec] HIP Registration Extension

Hi Julien,

On Tue, 19 Aug 2008, Julien Laganier wrote:
> Hi Lauri,
> Some more thougths...
>>
>>  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.

This would be reasonable behavior from the server. However, this is not 
implicit in the RFC and in my opinion needs clarification. The paragraph 
from the RFC above talks about "sending a REG_RESPONSE with a zero 
lifetime to _all_ registered requesters". Because of the word "all" there, 
the paragraph gives the impression that the server decides to remove the 
whole service from the supported services' pool and thus signals to all 
its clients the new set of supported services.

This is not what we want here. A server can support both RVS and full 
relay services at the same time but a single client cannot be registered 
to both these services simultaneously. Therefore, the server should send a 
REG_RESPONSE with a zero lifetime only to the client who sent the 
REG_REQUEST.

Also, because "the registrar MUST NOT include more than one REG_RESPONSE 
parameter in its R2 or UPDATE packets" the client will receive at least 
two packets in response to a sent REG_REQUEST in this case. The figure on 
[Page 3] is in conflict with this behavior.

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

This works but as I said earlier, at least two packets will be sent in 
response. With Failure Type "Cancellation required" this would not happen. 
Alternatively multiple REG_RESPONSEs could be allowed in one packet.

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

This is confusing for the server administrator. If the server supports two 
services S1 and S2 with lifetime boundaries configured as:

S1 min 30s   max 120s
S2 min 3600s max 86400s

the server would then signal [S1, S2 (30 86400)] in REG_INFO, and so the 
administrator's configurations are not respected.

Next, the client wants to register to service S2 for 3600 seconds and 
sends a REG_REQUEST [S2 (3600)]. The server then checks the lifetime 
boundaries for the service S2 again and sends a REG_RESPONSE [S2 (120)].

Yep, this works, but it is illogical to signal different lifetime 
boundaries than what are later granted. This issue could be easily fixed 
by allowing multiple REG_INFOs / REG_RESPONSEs / REG_REQUESTs in one 
packet or by altering the parameters' formats.

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

Fair enough, but this should be said in the RFC.

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

Hmmm...

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].

RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

So are "the full implications understood and carefully weighed" when the 
server does not send a REG_RESPONSE? "Carefully weighing" for me means 
that the issue is thought over and written in the RFC. I'm not saying this 
is an important point, but if the RFC is to be revised, the following 
clarification wouldn't hurt:

"The Requester SHOULD NOT assume that the cancellation was successful 
until it receives a REG_RESPONSE with a matching Reg Type and a zero 
lifetime."

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

Good point, but this would increase the administrative work.

-Lauri
_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec