[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] HIP Registration Extension (fwd)
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:
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.
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:
Failure Type Reason
------------ --------------------------------------------
2 Cancellation required
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
registration.
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.
[...]
1) How does a registrar announce that it is capable of providing multiple
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.
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.
Thus an additional specification would be required it seems.
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.
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.
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?
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
_______________________________________________
Hipsec mailing list
Hipsec at ietf.org
https://www.ietf.org/mailman/listinfo/hipsec