[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Hipsec] HIP Registration Extension

[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
Hipsec at ietf.org
https://www.ietf.org/mailman/listinfo/hipsec