Hi,
On Mon, 2006-01-30 at 13:08 -0800, ext Eddie Kohler wrote:
> At the last IETF several people expressed renewed interest in
> mobility and multihoming support for DCCP. I've updated my existing
> draft, and am interested in feedback:
Thanks for updating this draft! I like the general appoach taken in
the new version, and would like to see it become a working group item.
Some comments below, roughly in the order they came across when
reading the draft (nits not separated from other issues).
- Pasi
--------------------------
* Introduction doesn't motivate the reader very much. Rather, there
are sentences like "Unsurprisingly, we did not find a suitable
mechanism, and I now believe no such mechanism exists." that don't
sound encouraging :-) I think this draft presents a pretty good
attempt at providing mobility support for DCCP, so I might disagree
with this statement. Instead, it would be useful to list some
reasons for supporting mobility and multi-homing on transport layer,
such as:
- Interoperability between IPv4 and IPv6 network domains
- Providing possibility to efficiently utilize multiple interfaces
in multi-access hosts
- Giving an alternative that does not use home agent in the
network, which could be useful in the common case that the server
is fixed, especially if Mobile IP is not available for some
reason.
- etc.
* 3.1. Overview: "DCCP-Response with Accept Gencon" ==> "DCCP-Response
with Approve Gencon"
* It would be useful to be able to indicate preference level of the
component connections. Usually the mobile end has some kind of idea of
the priorities between different addresses, but the server does
not. The mobile end would indicate the preference level in Initiate
and Attach messages, which would therefore need a new protocol
field. As one possibility, I think GCType could be split into two
four-bit fields, as 15 values are probably sufficient for both
different preference levels and mobility message types.
* Layout of the Gencon option: I'm not sure about this, but would it
be more convenient for some computer architectures to have the 8-byte
Gencon ID field starting at a 32-bit word boundary? This would be
possible by having 3-byte component ID, which I'd believe to be
sufficient in practice even for long-lived connections. In that case
we could have the following message format:
byte 0: GCType (+ preference)
bytes 1-3: Component ID (3 bytes)
bytes 4-11: Gencon ID (8 bytes)
* It seems that Gencon ID is actually composed of two parts: one set
by the client host in the Initiate message, and another set by the
server in the Approve message. This separation could be made more
explicit by having separate 4-byte "Client Gencon ID" and 4-byte
"Server Gencon ID" instead of one 8-bit field.
* 3.3. Initiate Gencon Message: This document should specify at least
one key type and its format, or refer to some other document that
specifies it.
* The document should discuss how to reject component
connections. DCCP-Reset or DCCP-Close could be used, but I'm wondering
if there is a need for additional "soft reject" type that could use
the Detach message and equip it with a reason code. For example, we
could consider Detach to be used for the following cases:
1) Client proposes unknown key type. In future there might be a need
to a introduce new key types in addition to the default one, and hence
it would be useful to be able to negotiate a common key type, which is
unnecessarily difficult if the receiver just ignores the message.
2) Server supports the Gencon mechanism but disallows mobility to a
component connection for some reason.
3) One of the IP addresses used in a component connection is lost (the
original purpose of the Detach message)
* Receiver of Attach message is required to memorize and ignore
Component IDs that have already been used, which means in practice
that the Component IDs have to be allocated in incremental order. I
think it would be clearer to say this, and to say that receiver must
ignore the Attach message if Component ID <= last succesfully attached
component ID. I'd also try to allow wrapping of the ID range somehow,
even though it seems a very distant possibility that some Gencon would
use the whole 32-bit (or even 24-bit) range. Otherwise an infinite
Gencon comes to a state where it must be terminated because of lack of
component IDs.
* The Attach-Challenge-Confirm negotiation uses two nonces, one
generated by the Client and another generated by the Server. For
clarity, I think it would be better to call them "Client Nonce" and
"Server Nonce", or C-Nonce and S-Nonce, respectively. And to say that
Token in Challenge message uses C-Nonce, and token in Confirm message
uses S-Nonce.
* Page 10: "Nonce values MUST be chosen randomly, and MUST NOT be
reused" seems a tough requirement to be checked at both ends, if a
generalized connection has tens of mobility events during its
lifetime. Is this really needed to prevent replay attacks? Instead,
if it is required that a component connection server never re-uses the
same sequence number when responding to Attach messages in the same
component connection, doesn't it then satisfy the security
requirements? Because the expected acknowledgement in the Confirm
packet is then different for each Challenge response.
* Page 11: I think it would be clearer to present the token format as
similar ascii art as the other header formats.
* Page 11: "This structure is then encrypted using the _endpoint's_
private key". I would use _local endpoint's_.
* 3.8 Detach Gencon message: "Sometimes, however, an endpoint loses
control of a _generalized connection_..." I guess this should say
component connection.
* 3.9 Unexpected options: As said above, just ignoring messages with
unknown key type makes it difficult to negotiate a key type that is
understood by both. Rather, some kind of error response (e.g. in
Detach message) would seem more appropriate.
* Page 15: "endpoint SHOULD send its data on the last connection on
which it received data". This could go as likely wrong as being the
right choice, especially when the data flow is mostly unidirectional
from fixed source to mobile destination. If the Attach messages
indicated a preference value, the most prefered connection could be
used, in the lack of other external control.
* Page 15: "An endpoint SHOULD NOT use generalized connections simply
to improve its throughput with parallel connections. There SHOULD be
a substantive difference between the component connections". This
sounds a bit vague. How about simply requiring that any two component
connections in the same generalized connection MUST NOT use same
source/destination IP address pair. Anyway, I think the first sentence
quoted above is a useful reminder and applies even if using different
IP addresses on same host.
* Concerns section looks like it is missing some text yet, but I guess
that will get itself corrected in subsequent draft versions.
Attachment:
signature.asc
Description: This is a digitally signed message part