Hi Eddie, Thanks for quick response. A few additional notes to some of your comments below... On Tue, 2006-02-07 at 12:58 -0800, ext Eddie Kohler wrote: > > * 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. It doesn't have to be a universal preference system, just something by which the mobile end can indicate which of the component connections is the most prefered to be used in a particular Gencon. Another, much simpler approach could be just to assume that the most recent Attach message tells the prefered component connection. And changing the prefered component connection would be possible by resending an Attach message to an existing component connection using the same nonce and IP address as originally. > > * 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. ok, I can live with that :-) > > * 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". Ok. I think it is useful to say that in the draft, too. Though I'm not sure if a single general type is enough to tell the other end what went wrong. The initiating end might need to separate at least the two cases where a) the other end does not support mobility; b) the other end supports mobility, but does not support the key type. On the other hand, I guess it is possible to later specify a new Reset Code, if there is ever going to be more than one key type. At the present this is a preliminary concern, as currently we have 0 key types defined ;-) > > * 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? Frankly, I couldn't think of any other way to implement component ID allocation, so that it requires minimal state at both ends of the connection, and would enable wrapping back to the start in the unlikely case that the end of the component ID range has been reached (crossing hairs, "[Connection ID] MUST NOT have been used for any previous successful component connection" prevents this). But I guess you are right in that the implementation details are best left to implementors. One option could be to outline with couple of sentences the above as one implementation choice, and at the same time note that it is not fatal to wrap over in the end. > > * 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. "Nonce values MUST be chosen randomly, and MUST NOT be reused on the same generalized connection ID." seems a heavy combination to me. Both ends would need to maintain a growing list of used nonces for each connection, and for each new Attach and Challenge message both ends are expected to check that a new nonce does not overlap with any of the previously used nonces. A small handheld device could be memory constrained even with small number of connections, and a relatively busy server might need to maintain lots of connections with this kind of nonce list. I thought that for sequence numbers this could be easier, if the subsequent Attach or Challenge messages would not have to re-select a random sequence number, but rather just increment it in case the message needs to be resent. Alternatively, the draft could require that nonce must not be reused on the same *component connection ID*, instead of generalized connection ID. Isn't this sufficient, since having component ID in the token should prevent replay attacks in this case. And then the list of old nonces could be removed immediately after a succesful Attach-Challenge handshake. > > * 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. I'd think that a specific message type, or even re-sending Attach would be better. Better not to overload the semantics of empty data packets. > > * 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. Ah, that's a good point. Too bad, it would would have been nice to have a clear technical guideline on how to use component connections, to give the other end some tools to recognize and prevent this kind of behaviour. Well, I guess the above is better than nothing, but it's just that "substantive difference" could be almost anything: different address families, different routes (covered by failure dependencies, I guess), etc. - Pasi
Attachment:
signature.asc
Description: This is a digitally signed message part