Abstract
In this section, we discuss some issues in RFC 5203 as well as reveal some additional RVS and HIP relay features of HIPL.
Unfortunately RFC 5203: Host Identity Protocol (HIP) Registration Extension has some vaguely defined instructions. Some may call them features, some unanswered questions and some just plain design faults. What ever the case, we have had to take into account these issues when implementing the registration extension. We present these issues next:
While RFC 5203 provides us a way to request more than one service using single base exchange or UPDATE packet exchange, it does not provide us a way to do so using different lifetime boundaries. The REG_REQUEST and REG_RESPONSE parameters include only one lifetime field and thus we would need to use multiple parameters to request multiple lifetimes. In RFC 5203 it is said, however:
"The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets..."
"The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets..."
RFC 5203 provides us no instructions how to deal with REG_INFO, REG_REQUEST or REG_RESPONSE parameters that include duplicate "Reg Type" values, i.e. for example the registration type of RVS listed twice in one parameter.
RFC 5203 provides us no instructions how to deal with failed registration cancellations. That is, how should the client react when the server responses with a REG_FAILED parameter to a REG_REQUEST parameter having lifetime of zero?
These are the HIPL solutions for the three issues presented in the previous section:
The client cannot request multiple lifetimes. You can input only a single lifetime to "hipconf".
The server, on the other hand, uses the first given lifetime boundaries for every offered service in REG_INFO parameters (If "/etc/hip/relay_config" would provide a way to define individual lifetime boundaries for each service, the boundaries listed first would be used for every service).
If the client receives an REG_RESPONSE parameter with duplicate "Reg Types", it processes each registration type one after other. It is up to each service how the service reacts to a duplicate response. If the server receives an REG_REQUEST parameter that includes duplicate "Reg Types", the whole parameter is silently dropped.
Receiving a REG_FAILED as an response to a service cancellation is handled exactly the same was as a REG_FAILED received as an response to a service request. That is, the client just assumes that the server is not able to provide the requested service.
Client side commands i.e. commands run on the responder (server client).
Although HIPL currently only supports RVS, relay and escrow services, you can request for any service using the "hipconf" tool. This feature is provided for testing purposes, especially to test how HIPL reacts with other HIP implementations that have the registration extension implemented.
The services are identified by "Reg Types" i.e. numbers between 0 and 255 (both inclusive). Instead of using the predefined strings, you can use these service numbers to request a service. For example, to request a service identified by number 1 (the rendezvous service), you can type
tools/hipconf add server 1 <SERVER-HIT> <SERVER-IP> <LIFETIME-IN-SECONDS>
Notice, however, that if the server does not support the service you have requested, a request is never sent.
To request multiple services using one service request you can chain the service types. For example, to request services identified by registration types 3, 10 and 245 you can type:
tools/hipconf add server 3 10 245 <SERVER-HIT> <SERVER-IP> <LIFETIME-IN-SECONDS>
Using this chaining method one can request up to ten services with one REG_REQUEST parameter.
To cancel multiple service registrations using one service request you can chain the service types as with registration.
tools/hipconf del server 3 10 245 <SERVER-HIT> <SERVER-IP>
Using this chaining method one can request up to ten service cancellations with one REG_REQUEST parameter.
17th of July 2008