Re: [Hipsec] HIP Registration Extension (fwd)

[Julien Laganier <[e-mail]>]

Hi Lauri,

Lauri Silvennoinen wrote:
> Hi all,
> 
> I asked a few questions related to the HIP Registration Extension back 
> on April, but I think I never got an answer to these questions. The 
> draft is now known as RFC 5203, but the issues remain unanswered. So I 
> send my previous mail again, hoping to get an answer this time.

Sorry for not answering before. Better later than never :)

Some comments inlined below:

> In addition to the issues presented below, I would like to propose a new 
> Failure Type to be used in the REG_FAILED parameter. We have currently 
> two Failure Types defined:
> 
>     Failure Type    Reason
>     ------------    --------------------------------------------
>     0               Registration requires additional credentials
>     1               Registration type unavailable
> 
> Now, when the server is able to provide multiple services and some of 
> these services cannot co-exist i.e. a single requester cannot be 
> registered to these services simultaneously, how does the server respond 
> to a registration attempt?
> 
> For example, if a server is able to provide both rendezvous service and 
> full relay for HIP packets service (used in ICE), a single requester 
> cannot be allowed to register to both of these services without 
> canceling the previously granted service first.

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.

> For this type of situation, I suggest a new Failure Type:
> 
>     Failure Type    Reason
>     ------------    --------------------------------------------
>     2               Cancellation required

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?

> The other possibility would be to just silently overwrite the previous 
> registration.

Silent overwriting wouldn't be good. The registrar should grant the new 
registration and cancel the old one (see below excerpt from Sec. 5 of 
RFC 5203), or vice versa:

    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.

[...]

> 1) How does a registrar announce that it is capable of providing multiple
>    services with different lifetimes?

When we wrote that spec we didn't foresee such a usecase. The lifetime 
was on per-server basis, i.e. the time the server is willing to provide 
registrations, the time it expects to stay up, etc.

>     In Section 3.1 it is said that "a registrar SHOULD include a REG_INFO
>     parameter in the R1 packets it sends during all base exchanges." The
>     REG_INFO parameter, however, is of the following form:
> 
>         0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             Type              |             Length            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Min Lifetime  | Max Lifetime  |  Reg Type #1  |  Reg Type #2  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      ...      |     ...       |  Reg Type #n  |               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Padding    +
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     I.e. it has single "Min Lifetime" and "Max Lifetime" values. The issue
>     would be solved if the registrar could include multiple REG_INFO
>     parameters in the R1 packets, but nothing is said about multiple
>     REG_INFOs in the draft.

Thus an additional specification would be required it seems.

> 2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters that
>    have redundant services? These parameters are of the following form:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             Type              |             Length            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Lifetime    |  Reg Type #1  |  Reg Type #2  |  Reg Type #3  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      ...      |     ...       |  Reg Type #n  |               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Padding    +
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>     Now, what happens if, say, both "Reg Type #1" and "Reg Type #2" are of
>     type RVS? Not that it would make any sense to build such parameters, 
> but
>     the hosts should be ready to handle such parameters.

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.

> 3) What happens if registration cancellation does not succeed? In Section
>    5 it is said:
> 
>     "A zero lifetime is reserved for canceling purposes.  Requesting a zero
>     lifetime for a registration type equals to canceling the registration
>     of that type.  A requester MAY cancel a registration before it expires
>     by sending a REG_REQ to the registrar with a zero lifetime.  A
>     registrar SHOULD respond and grant a registration with a zero lifetime.
>     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."
> 
>     Thus if the requester wants to cancel a service it sends a REG_REQUEST
>     parameter with zero lifetime to which the registrar should answer with
>     a REG_RESPONSE with zero lifetime respectively. But what happens if the
>     registrar is unable to cancel the registration due to transient
>     conditions or some other reason? Does the registrar just remain silent
>     or send a REG_FAILED?

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. Do you think more text is needed?

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