Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?

[Peter Deacon <peterd@iea-software.com>]

On Tue, 22 Feb 2011, Alan DeKok wrote:

> > I agree with you it is better not to go there if not absolutely
> > necessary and in this case it may not be but old ports are now
> > potholes... and this scares me.

> > These things should be in the RDTLS draft. It would stink if someone
> > used a "connected" socket and (IMHO naturally) tried to reconnect the
> > TLS channel using the same socket(src port).. and when doing this some
> > servers sometimes did not accept the new connection for some period of
> > time because of this behavior.

>  That is an issue, unfortunately.  The solution is largely to have
> graceful shutdowns, and don't re-use ports.

Some thoughts:

It seems possible one would have the freedom to implement a _server_ with 
broadcasting to fill the potholes or even remove source port from the 
tuple while still maintaining 100% interoperability with clients and 
servers following this draft as currently written.  I agree it is not a 
particularly good idea but at least it is workable.

Here is an alternate proposal to resolve issues and make transport more 
reliable and easier for developers to implement client and server codes.

List of issues:

1. Stealing type codes is bad form even if we all think noone is using them

2. Multiple DTLS sessions to the same server is an unnecessary waste of 
resources and may lead to unnecessary confusion regarding connection state 
should one but not all sessions under management be disconnected without 
the peers knowledge.

3. Client must implement strategies to maintain multiple connections if 
they need to effectively deal with the problem of insufficient ID space.

4. Expecting NATs to maintain long term stateful UDP mappings in sync with 
underlying DTLS session is not something I would want to bet on.  Mapping 
request and response is all RADIUS currently has to do.. It is much 
different than expecting the whole train of all subsequent requests to 
continue to use the same source port...

5. Potholes.

6. Depending on DTLS packet formatting and content type parameters to not 
change in the future for compatibility with the detection method is not 
ideal.

What I propose is allocating two type codes used for all RDTLS requests.

RDTLS-Request
RDTLS-Response

They will be used in a simple 4-byte prefix before the DTLS data by RADIUS 
clients and servers.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |               RDTLS-Session-ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  DTLS ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

Clients send code RDTLS-Request
Servers send code RDTLS-Response


Clients seeking new connections set RDTLS-Session-ID to 0.

Servers respond setting an internal value corresponding with the session 
table during the DTLS handshake.

Clients subsequently resend RDTLS-Session-ID for all future requests 
against the session.

Clients wishing new session send RDTLS-Session-ID = 0.

The tracking table in 4.1 is changed to replace source port with the 
RDTLS session id.

regards,
Peter

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>