Subject: [Hipsec] How to maintain a registered service?

From: Miriam Esteban <[email-masked]>
Date: Fri, 28 Oct 2005 11:30:13 +0200

Dear all,

While rereading the drafts about rvs and registration I have 
seen that there is nothing defined yet about  how to maintain this 
registration alive.

I have one proposal for this. 
This consists of the REQUESTER sending one UPDATE packet with a REG_REQUEST 
parameter to the REGISTRAR. This packet should be send  before the lifetime 
of the registered service is finished. If not, the REGISTRAR should remove 
the services registered by the REQUESTER.

   +-----+                                           +-----+-----+
    |       |  						 |       |        |
    |       |  UPDATE(REG_REQ:S)  |       |        |      
    |RQ |   ---------------------------->    |  R  |  S    |
    |       |   					 |  	 |        |
    |       |  UPDATE(REG_RESP:S)|       |        |
    |       |   <--------------------------      |       |        |
   +-----+                                          +-----+-----+

This proposal conflicts with what it is said in 
draft-ietf-hip-registration-00.

   "Moreover, the requester MUST NOT include the
   parameter unless the registrar's R1 packet or latest received UPDATE
   packet has contained a REG_INFO parameter with the requested
   registration types."
--- Talking about REG_REQUEST parameter----

Then, this maintaining process as it's explained here should be like it's 
reported in the draft:

   +-----+                                           +-----+-----+
    |       |  UPDATE(REG_INFO:S)  |       |        |
    |       |   <--------------------------       |       |        |
    |	    |				                  |       |        |
    |       |  UPDATE(REG_REQ:S)   |       |        |      
    |RQ |   ---------------------------->     |  R  |  S    |
    |       |   					  |       |        |
    |       |  UPDATE(REG_RESP:S) |       |        |
    |       |   <--------------------------       |        |       |
   +-----+                                           +-----+-----+

I don't see why it's necessary that the REGISTRAR is the one to trigger this 
process in the service maintainance. Maybe because the lifetimes are supposed 
quite big and the information about the services might have changed? What 
happens if the REQUESTER changes its IP address at the same moment before 
receiving the REG_INFO? Does the REGISTRAR have to start retransmitting the 
UPDATE with the REG_INFO parameter? I don't really see why it should be like 
this. Could you please help me with that?

I do really think this is an issue one of these documents should include. 
For instance, it would be a part to add (as I see it) as point 3.4 in 
draf-ietf-hip-rvs-04. Also in point 5 in draft-ietf-hip-registration-00.

Or maybe it's not there because it's considered an implementation issue?

Thanks!

Miriam

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Fri, 28 Oct 2005 17:18:02 +0200

Hi Miriam,

Thanks for bringing this issue to our attention. More thoughts are 
inlined below:

> seen that there is nothing defined yet about  how to maintain this

I don't think that the specification does not allow a requester to 
prolong a registration. 

> This consists of the REQUESTER sending one UPDATE packet with a
> REG_REQUEST parameter to the REGISTRAR. This packet should be send 
> before the lifetime of the registered service is finished. If not,
> the REGISTRAR should remove the services registered by the
> REQUESTER.

+-----+                             +-----+-----+
|     |  UPDATE(REG_REQ:S)          |     |     |
| RQ  |---------------------------->|  R  |  S  |
|     |  UPDATE(REG_RESP:S)         |     |     |
|     |<----------------------------|     |     |
+-----+                             +-----+-----+

>    parameter unless the registrar's R1 packet or latest received
> UPDATE packet has contained a REG_INFO parameter with the requested
> registration types."
> Then, this maintaining process as it's explained here should be
> like it's reported in the draft:
>
+-----+                             +-----+-----+
|     |  UPDATE(REG_INFO:S)         |     |     |
|     |<----------------------------|     |     |
|     |  UPDATE(REG_REQ:S)          |     |     |
| RQ  |---------------------------->|  R  |  S  |
|     |  UPDATE(REG_RESP:S)         |     |     |
|     |<----------------------------|     |     |
+-----+                             +-----+-----+

> I don't see why it's necessary that the REGISTRAR is the one to
> trigger this process in the service maintainance. Maybe because the
> lifetimes are supposed quite big and the information about the
> services might have changed?

It does not conflict. If a registration types is available (i.e. 
announced in R1 or UPDATE) the requester to re-register before the 
registration expire (i.e. prolong it). What is forbidden is to 
register with a service currently unavailable (i.e. not announced in 
R1 or in the last UPDATE.)

In other words, a prolongation via another REG_REQ, REG_REP exchange 
does not require that an UPDATE is sent by the registrar before hand.

If people think that is unclear maybe we need to clarify this point.

> What happens if the REQUESTER changes 
> its IP address at the same moment before receiving the REG_INFO?
> Does the REGISTRAR have to start retransmitting the UPDATE with the
> REG_INFO parameter? 

The requester changing its IP address is IMO orthogonal to the 
registration maintenance. The requester would notify the registrar by 
sending an UPDATE containing a LOCATOR with its new IP address. Then 
the registrar would update its location table.

> I don't really see why it should be like this. 
> Could you please help me with that?

I hope the above clarify things...

> Or maybe it's not there because it's considered an implementation

I think it the current specification forbids neither to prolong a  
registration, nor to update the requester IP address (FWIW even the 
registrar can update its IP address.) 

So IMHO it is implicit that a registration can be prolonged, but as I 
said before, if people think that a clarification is necessary then 
we could do that. 

Thanks again.

--julien