Subject: [Hipsec] HIP Registration Extension (fwd)

From: Lauri Silvennoinen <[email-masked]>
Date: Thu, 14 Aug 2008 20:40:54 +0300 (EEST)

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

---

From: Julien Laganier <[email-masked]>
Date: Mon, 18 Aug 2008 18:55:25 +0200

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:

> Failure Type to be used in the REG_FAILED parameter. We have currently 
> two Failure Types defined:
> 
>     Failure Type    Reason
> 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:

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 

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.

[...]

>    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.

>     REG_INFO parameter, however, is of the following form:

Thus an additional specification would be required it seems.

>    have redundant services? These parameters are of the following form:

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.

>     conditions or some other reason? Does the registrar just remain silent

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

---

From: Lauri Silvennoinen <[email-masked]>
Date: Tue, 19 Aug 2008 20:32:59 +0300 (EEST)

On Mon, 18 Aug 2008, Julien Laganier wrote:

Hi Julien,

>> ...
> 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.

It can and should be considered as an error from the Requester. However, 
this does not mean that the Requester cannot send such a message. I'm 
mostly concerned about the server implementation in all of the issues. 
Thus the question is: how does the server respond to a registration 
attempt having services that cannot co-exist. RFC 5203 does not provide 
instructions for this. Are you suggesting that the server should just 
silently drop such a request? If so, this should be put in clear text into 
the RFC.

>> ...

This would be even better, but then we would need individual Failure Types
for each registration that needs to be cancelled. So instead of

     Failure Type    Reason

we would have for example:

     Failure Type    Reason
     ------------    --------------------------------------------
     101             RVS Cancellation required
     102             HIP RELAY Cancellation required
     103             ...
     ...

This could get too complicated when the number of HIP services (and HIP 
service related specifications) increases. So I would stick to the single 
"Cancellation required" value instead and let it be local policy at the 
Requester to know which services cannot co-exist. Either way, isn't it 
better to signal "Cancellation required" than "Registration requires 
additional credentials" or "Registration type unavailable" (or to remain 
silent) in this case?

>> ... 
>> but nothing is said about multiple REG_INFOs in the draft.
>

Yes.

>> ...
> 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.

Broken behavior yes, but again, the RFC does not state in clear text how 
to handle such a case. If a REG_REQUEST has redundant services, then it's 
broken behavior at the Requester side. If a REG_RESPONSE or a REG_FAILED 
has redundant services, then it's broken behavior at the Registrar side. 
I suggest the following:

The REG_REQUEST case i.e. the client has requested redundant services. The 
server should not allow any broken behavior from the client. Therefore 
the whole packet having redundant services should be just silently 
dropped. Note that the process of handling the REG_REQUEST parameter at 
the server involves the creation of some kind of registration state and 
that this creation can be time and resource consuming.

The REG_RESPONSE and REG_FAILED cases i.e. the server has granted/denied 
redundant services. This should be a local policy issue at the client. If 
the server shows broken behavior, the client can always choose to use 
another server.

>> ...
> 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.

Perhaps this could be clarified by saying "The Requester cannot assume 
that the cancellation was successful until it receives a REG_RESPONSE with 
a zero lifetime."

> Do you think more text is needed?

Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max 
Lifetime" / "Lifetime" values.

-Lauri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 19:47:58 +0200

Hi Lauri,

Some more thougths...

Lauri Silvennoinen wrote:
> silently drop such a request? If so, this should be put in clear text 
> into the RFC.

I think since the RFC allows the server to cancel the earlier 
registration (sending

> service related specifications) increases. So I would stick to the 
> single "Cancellation required" value instead and let it be local policy 
> at the Requester to know which services cannot co-exist. Either way, 
> isn't it better to signal "Cancellation required" than "Registration 
> requires additional credentials" or "Registration type unavailable" (or 
> to remain silent) in this case?
> 
>>> ... but nothing is said about multiple REG_INFOs in the draft.
>>
> to handle such a case. If a REG_REQUEST has redundant services, then 
> it's broken behavior at the Requester side. If a REG_RESPONSE or a 
> REG_FAILED has redundant services, then it's broken behavior at the 
> Registrar side. I suggest the following:
> 
> The REG_REQUEST case i.e. the client has requested redundant services. 
> The server should not allow any broken behavior from the client. 
> Therefore the whole packet having redundant services should be just 
> silently dropped. Note that the process of handling the REG_REQUEST 
> parameter at the server involves the creation of some kind of 
> registration state and that this creation can be time and resource 
> consuming.
> 
> redundant services. This should be a local policy issue at the client. 
> If the server shows broken behavior, the client can always choose to use 
> another server.
> 
>> 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.
> 
> that the cancellation was successful until it receives a REG_RESPONSE 
> with a zero lifetime."
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 19:57:33 +0200

[sorry for resent, wronly hit CTRL+ENTER]

Hi Lauri,

Some more thougths...

I think since the RFC allows the server to cancel the earlier 
(incompatible) registration, then it should do that, and grant the new one:

> for each registration that needs to be cancelled. So instead of

Defining new failure types wouldn't be good. I was thinking more about 
piggybacking to the REG_FAILED for "cancellation required" with a 
REG_TYPES_TO_CANCEL parameter containing the registrations types that 
shall be cancelled before the requested registration is granted. But 
that seems to complex. Since this is somehow an error case from the 
requester I think we should do as I suggested earlier, i.e. the 
registrar signal that incompatible registations were cancelled, and 
accpet the new one.

>> Thus an additional specification would be required it seems.

I am not sure it is required to indicate different lifetimes for 
different services though. If you really want to handle various 
lifetime, you can get the same result by announcing the min lifetime of 
services you're offering for all services.

> silently dropped. 

I disagree. If we follow the "be conservative in what you send, liberal 
in what you accept", a peer receiving duplicate registration types 
should just ignore the duplicated occurrences.

> Note that the process of handling the REG_REQUEST 

I think this is implicit in the specification, don't you think so?

> Lifetime" / "Lifetime" values.

As I said, not sure that's really needed for any usecase. And in case 
you really have a hard requirement to support that, you could configure 
different Registrars announcing different lifetimes w/ different HITs on 
the same node. That can be left to implementation.

--julien

---

From: Lauri Silvennoinen <[email-masked]>
Date: Wed, 20 Aug 2008 21:02:37 +0300 (EEST)

Hi Julien,

On Tue, 19 Aug 2008, Julien Laganier wrote:
> Hi Lauri,
> Some more thougths...
>>
>>  It can and should be considered as an error from the Requester.
>>  However, this does not mean that the Requester cannot send such a
>>  message. I'm mostly concerned about the server implementation in all
>>  of the issues. Thus the question is: how does the server respond to a
>>  registration attempt having services that cannot co-exist. RFC 5203
>>  does not provide instructions for this. Are you suggesting that the
>>  server should just silently drop such a request? If so, this should be
>>  put in clear text into the RFC.
>

This would be reasonable behavior from the server. However, this is not 
implicit in the RFC and in my opinion needs clarification. The paragraph 
from the RFC above talks about "sending a REG_RESPONSE with a zero 
lifetime to _all_ registered requesters". Because of the word "all" there, 
the paragraph gives the impression that the server decides to remove the 
whole service from the supported services' pool and thus signals to all 
its clients the new set of supported services.

This is not what we want here. A server can support both RVS and full 
relay services at the same time but a single client cannot be registered 
to both these services simultaneously. Therefore, the server should send a 
REG_RESPONSE with a zero lifetime only to the client who sent the 
REG_REQUEST.

Also, because "the registrar MUST NOT include more than one REG_RESPONSE 
parameter in its R2 or UPDATE packets" the client will receive at least 
two packets in response to a sent REG_REQUEST in this case. The figure on 
[Page 3] is in conflict with this behavior.

> registrar signal that incompatible registations were cancelled, and 

This works but as I said earlier, at least two packets will be sent in 
response. With Failure Type "Cancellation required" this would not happen. 
Alternatively multiple REG_RESPONSEs could be allowed in one packet.

> services you're offering for all services.

This is confusing for the server administrator. If the server supports two 
services S1 and S2 with lifetime boundaries configured as:

S1 min 30s   max 120s
S2 min 3600s max 86400s

the server would then signal [S1, S2 (30 86400)] in REG_INFO, and so the 
administrator's configurations are not respected.

Next, the client wants to register to service S2 for 3600 seconds and 
sends a REG_REQUEST [S2 (3600)]. The server then checks the lifetime 
boundaries for the service S2 again and sends a REG_RESPONSE [S2 (120)].

Yep, this works, but it is illogical to signal different lifetime 
boundaries than what are later granted. This issue could be easily fixed 
by allowing multiple REG_INFOs / REG_RESPONSEs / REG_REQUESTs in one 
packet or by altering the parameters' formats.

> should just ignore the duplicated occurrences.

Fair enough, but this should be said in the RFC.

>> >  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 

Hmmm...

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].

RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

So are "the full implications understood and carefully weighed" when the 
server does not send a REG_RESPONSE? "Carefully weighing" for me means 
that the issue is thought over and written in the RFC. I'm not saying this 
is an important point, but if the RFC is to be revised, the following 
clarification wouldn't hurt:

"The Requester SHOULD NOT assume that the cancellation was successful 
until it receives a REG_RESPONSE with a matching Reg Type and a zero 
lifetime."

> the same node. That can be left to implementation.

Good point, but this would increase the administrative work.

-Lauri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 26 Aug 2008 11:51:48 +0200

On Wednesday 20 August 2008, Lauri Silvennoinen wrote:
> >>  message. I'm mostly concerned about the server implementation in
> >> all of the issues. Thus the question is: how does the server
> >> respond to a registration attempt having services that cannot
> >> co-exist. RFC 5203 does not provide instructions for this. Are you
> >> suggesting that the server should just silently drop such a
> >> request? If so, this should be put in clear text into the RFC.
> >
> >    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.
>
> This would be reasonable behavior from the server. However, this is
> not implicit in the RFC and in my opinion needs clarification. The
> paragraph from the RFC above talks about "sending a REG_RESPONSE with
> a zero lifetime to _all_ registered requesters". Because of the word
> "all" there, the paragraph gives the impression that the server
> decides to remove the whole service from the supported services' pool
> and thus signals to all its clients the new set of supported
> services.
>
> relay services at the same time but a single client cannot be
> registered to both these services simultaneously. Therefore, the
> server should send a REG_RESPONSE with a zero lifetime only to the
> client who sent the REG_REQUEST.

I do not see the 'all' part as being that problematic. The spec says a 
registration may be cancelled by the registrar, that seems sufficient 
for the usecase we're discussing here.

> Also, because "the registrar MUST NOT include more than one
> REG_RESPONSE parameter in its R2 or UPDATE packets" the client will
> receive at least two packets in response to a sent REG_REQUEST in
> this case. The figure on [Page 3] is in conflict with this behavior.

Well, somehow these figures are informative only, the normative text is 
in Section 4. "Parameter Formats and Processing".

> > Defining new failure types wouldn't be good. I was thinking more
> > about piggybacking to the REG_FAILED for "cancellation required"
> > with a REG_TYPES_TO_CANCEL parameter containing the registrations
> > types that shall be cancelled before the requested registration is
> > granted. But that seems to complex. Since this is somehow an error
> > case from the requester I think we should do as I suggested
> > earlier, i.e. the registrar signal that incompatible registations
> > were cancelled, and accpet the new one.
>
> This works but as I said earlier, at least two packets will be sent
> in response. With Failure Type "Cancellation required" this would not
> happen. Alternatively multiple REG_RESPONSEs could be allowed in one
> packet.

I do not see the two packets as problematic.

> > lifetime, you can get the same result by announcing the min
> > lifetime of services you're offering for all services.
>
> This is confusing for the server administrator. If the server
> supports two services S1 and S2 with lifetime boundaries configured
> as:
>
> S1 min 30s   max 120s
> S2 min 3600s max 86400s
>
> the server would then signal [S1, S2 (30 86400)] in REG_INFO, and so
> the administrator's configurations are not respected.
>
> boundaries than what are later granted. This issue could be easily
> fixed by allowing multiple REG_INFOs / REG_RESPONSEs / REG_REQUESTs
> in one packet or by altering the parameters' formats.

It's not that illogical given that it's allowed by the spec:

   The requester MUST be prepared to receive any registration lifetime,
   including ones beyond the minimum and maximum lifetime indicated in
   the REG_INFO parameter.  It MUST NOT expect that the returned
   lifetime will be the requested one, even when the requested lifetime
   falls within the announced minimum and maximum.

> >>  The REG_REQUEST case i.e. the client has requested redundant
> >> services. The server should not allow any broken behavior from the
> >> client. Therefore the whole packet having redundant services
> >> should be just silently dropped.
> >
> > I disagree. If we follow the "be conservative in what you send,
> > liberal in what you accept", a peer receiving duplicate
> > registration types should just ignore the duplicated occurrences.
>

Well, I think it's reasonable to expect some common sense from an 
implementor -- And we could even debatable if duplicate service 
announcements really constitues an error...

> >> >  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.
> >>
> >>  Perhaps this could be clarified by saying "The Requester cannot
> >> assume that the cancellation was successful until it receives a
> >> REG_RESPONSE with a zero lifetime."
> >
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be interpreted as described in RFC 2119
> [RFC2119].
>
> RFC 2119:
>
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
> there may exist valid reasons in particular circumstances to ignore a
> So are "the full implications understood and carefully weighed" when
> the server does not send a REG_RESPONSE? "Carefully weighing" for me
> means that the issue is thought over and written in the RFC. I'm not
> saying this is an important point, but if the RFC is to be revised,
> the following clarification wouldn't hurt:
>

Again, common sense IMHO covers that, but agree clarifying in a rev of 
the RFC would do no harm.

> >>  Yes, at least for the "Reg Types" with different "Min Lifetime" /
> >> "Max Lifetime" / "Lifetime" values.
> >
> > As I said, not sure that's really needed for any usecase. And in
> > case you really have a hard requirement to support that, you could
> > configure different Registrars announcing different lifetimes w/
> > different HITs on the same node. That can be left to
> > implementation.
>
 
--julien