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

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> 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.

  Yes.

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

  Yes.  It's less bad because the type code being stolen is a *response*
code.  So it shouldn't be sent to servers.

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

  Quite possibly, yes.  However, the limited ID space is an issue.

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

  Yes.  This is the same as today.

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

  If the client is continually sending traffic, it's OK.  The document
suggests a watchdog timer, which means at least one packet every few
tens of seconds.  That *may* be enough to keep the NAT state active.

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

  Pretty much, yes.

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

  If we're doing that, we might as well solve the ID limitation at the
same time.  Add a 64-bit unique "packet identifier", so that one DTLS
session can transport more than 256 RADIUS packets at the same time.

  This worries me a little, though.  It involves the creation of a new
protocol, which is neither RADIUS nor DTLS.  I'm not sure it solves
enough problems to warrant the extra complexity.

  Alan DeKok.

--
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/>