[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking table
On Mon, 21 Feb 2011, Alan DeKok wrote:
IMHO, that is a very bad idea, and quite likely impossible to
implement in practice. If you have two DTLS sessions from a client, and
packets from more than two different source ports, you'll need to
somehow inspect the traffic to determine which packet belongs to which
session.
It is quite easy to implement but I agree with your sentiment.
This approach will cut down on the number of DTLS sessions in a busy
environment and simplify implementations. If you want to support NATs and
the like you still can by broadcasting the packet to all matching DTLS
sessions.
Ouch. With 100 sessions, that means every packet results in 99 failures.
I don't think that's a good idea at all.
1:100 NAT does not work in RADIUS nor does it work in DTLS so why should I
care about this ridiculous example?
If someone is gonzo enough to run a 100 sessions thru a 1:100 NAT then
they deserve to waste each and every CPU cycle that entails.
Actually if you track the jitter window of the incoming datagram against
the sequence number for each session you can substantially pair down the
number of attempts.
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/>