Subject: [radext] Asking for consensus on DTLS

From: Alan DeKok <[email-masked]>
Date: Thu, 08 Nov 2012 15:35:40 -0500

There have been issues raised with DTLS.  I'm asking for explicit
statements from members of the WG on the following questions:

1) "silently discard".  When RFC 2865, 2866, etc. says a RADIUS packet
should be "silently discarded", what should happen with the DTLS session?

	a) nothing

	b) it should be closed

  If possible, I'd appreciate a one-sentence explanation as to why.

2) should we allow multiple independent, active, DTLS sessions from
   the same source IP/port to the same server destination IP / port?

	a) yes

	b) no

  Thanks.

  I'd like to get responses quickly, and I'll rev the doc next week.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2012 15:57:49 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> 2) should we allow multiple independent, active, DTLS sessions
    Alan> from the same source IP/port to the same server destination IP
    Alan> / port?

    Alan> 	a) yes

    Alan> 	b) no

No. This seems to introduce complexity and I don't see why it is needed.
If you need multiple sessions use a new port.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 8 Nov 2012 13:42:43 -0800 (Pacific Standard Time)

> If you need multiple sessions use a new port.

To clarify I am not advocating a need for multiple DTLS sessions per 
IP/Port.  I am advocating a solution to other issues which happen to 
allow this as a possibility.

I believe following issues need to be addressed:

1. What happens when a client attempts a new DTLS session from IP/source 
for which a server already has an active association?

2. Added implementation complexity involved with having to maintain 
multiple DTLS sessions to server to workaround insufficient per port ID 
space.

3. Consequence of UDP NAT association lifetime and effect on otherwise 
perfectly good DTLS sessions.

I am seeking to avoid problems caused by loss of synchronization between 
client and server view of DTLS session state.  Each instance of such a 
problem can be costly in terms of unnecessary delay required to correct it.

Clients have no way of tell the difference between packet loss and server 
ignoring requests due to (effective) DTLS session closure.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 08 Nov 2012 18:01:16 -0500

> allow this as a possibility.

  I find it instructive that you responded to Sam, rather than answering
the two simple questions I posed.

  i.e. your opinion is that you can ignore calls for WG consensus.
Instead, you just repeat your position.

  I think that further discussion is pointless.  I have responded to
your comments in detail.  You "respond" to mine by repeating your
position, without referencing anything I said.

  I've asked you specific questions, and gotten silence in response.
You are not respecting my attempt to engage you in a conversation.

  If your approach is to win the argument by simple attrition, it won't
work.  I've been doing this for 15 years.  I'm not going away.

  Bringing up non-DTLS problems is a blatant attempt to derail this
document.  It won't work.  This document is about DTLS.  Other issues
are out of scope.

  I've respected you enough to understand your position, and explain why
I disagree.  You need to do the same.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 8 Nov 2012 15:26:49 -0800 (Pacific Standard Time)

> the two simple questions I posed.

Hi Alan,

I felt it necessary to respond because I felt the question posed was not 
representative of the underlying question at issue.  Perhaps I could have 
done so with fewer characters.

In the end my only goal is to support a robust specification for RADIUS 
over DTLS.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 08 Nov 2012 18:49:34 -0500

Peter Deacon wrote:
> representative of the underlying question at issue.

  You could have said that.  You chose not to.

  I understand your position.  I just don't think it's relevant.

  You clearly don't understand my position.

  Alan DeKok.