[Hipsec] HIP Registration Extension (fwd)

[Lauri Silvennoinen <[e-mail]>]

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.

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.

For this type of situation, I suggest a new Failure Type:

     Failure Type    Reason
     ------------    --------------------------------------------
     2               Cancellation required

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

Best regards,
Lauri



---------- Forwarded message ----------
Date: Mon, 14 Apr 2008 16:30:40 +0300 (EEST)
From: Lauri Silvennoinen

Hi,

I am implementing / improving the existing implementation of the HIP
Registration Extension for InfraHIP project (HIPL). I have a few questions
concerning draft-ietf-hip-registration-02:

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

     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.

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.

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?

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