[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] DCCP mobility and multihoming

Hi Pasi, thanks for the comments!

On Feb 7, 2006, at 7:21 AM, Pasi Sarolahti wrote: 
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.

I agree. The text of the current introduction is written at a different audience, namely those people who thought mobility could be done WITHOUT CRYPTOGRAPHY. (The current mobility system does use cryptography.) I'd like long term to keep the current text in a subsection.

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

I disagree with this approach; if we really think we can specify a universal preference system, let's make the Gencon message bigger, and add a Gencon type for changing the preference. But I'm not sure we can do that.


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

DCCP options, of which Gencon is one, may explicitly begin on any byte boundary, and 8-byte values on some architectures must begin on an 8-byte boundary, so I'm not sure how much this would help. Implementors?


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


I guess I like it the way it is.


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


I agree!  But didn't want to do that right away :)


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

I think all of this will be taken care of with a DCCP-Reset message with a new Reset Code, "Gencon", meaning "I didn't like your Gencon 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.

That seems like a valid implementation choice, but not the only one. Why specify it?


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


Not a bad idea.


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

Is no-sequence-number-reuse any easier to implement than no-nonce- value-reuse? This thought occurred to me, but it seemed cleaner just to prevent nonce reuse.


* Page 11: I think it would be clearer to present the token format as
similar ascii art as the other header formats.


Not a bad idea.


* Page 11: "This structure is then encrypted using the _endpoint's_
private key". I would use _local endpoint's_.


OK


* 3.8 Detach Gencon message: "Sometimes, however, an endpoint loses
control of a _generalized connection_..." I guess this should say
component connection.


Yep!


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

I think you're right; if the endpoint understands Gencon, but not the type, it should reset.


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

I was imagining that an endpoint that wanted to change its preference would send an empty Data packet (a Data packet with no payload). But perhaps data preference should be specified with another Gencon message type, or with a feature.


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

Did the stuff after the comma, "There SHOULD be a substantive
difference between the component connections, such as different network
access technologies or failure dependencies.", make sense? Although I like your requirement, it breaks in the case of NAT, which can make different paths share an apparent IP address; but I'm not sure whether that breakage case is super relevant.


* Concerns section looks like it is missing some text yet, but I guess
that will get itself corrected in subsequent draft versions.


Yep :)


E