Subject: [Hipsec] HIP Registration Extension

From: Lauri Silvennoinen <[email-masked]>
Date: Mon, 14 Apr 2008 16:30:40 +0300 (EEST)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec