On Mon, 21 Feb 2011, Alan DeKok wrote:
Peter Deacon wrote:Isn't this what client hello /w cookies and the secure handshakes are for? Surely these can't be spoofed so easily?!
This is assuming you get that far. My assumption is that maintaining
multiple DTLS sessions for the same {src ip/port dst ip/port}
combination is a bad idea. I do not know the security implications of
doing it, and I don't think I'm enough of a TLS expert to say.
There are no implications. DTLS does not know or care about the underlying transport. It does not know what "UDP" is. If the transport can't handle app data it does not know about then there are much bigger problems because its trivial for anyone to spoof such packets.
Given a choice I prefer whatever gets characterized as impractical, ugly, unacceptable hacks if they translate into operational reduction in unreliable behavior and happy customers.
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.
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/>