Subject: [radext] New DTLS document

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Apr 2013 09:54:06 -0400

http://tools.ietf.org/html/draft-ietf-radext-dtls-05

  Which addresses all of the open concerns.

  Alan DeKok.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 17 Apr 2013 16:04:55 +0200

Thanks Alan.

- Jouni
17.4.2013 16.54 "Alan DeKok" <[email-masked]> kirjoitti:

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Apr 2013 10:26:15 +0300

Folks,

<as a co-chair>

Everybody happy with -05 ? If I here no immediate 
voices of disagreement, we can conclude the WG
has reached consensus and the document can move
forward. I'll wait till next Monday.

- Jouni

---

From: Peter Deacon <[email-masked]>
Date: Sun, 21 Apr 2013 11:43:33 -0700 (Pacific Daylight Time)

> Everybody happy with -05 ? If I here no immediate

Yep, thank you.

regards,
Peter

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 22 Apr 2013 05:32:46 +0000

I think there are a few inconsistencies that need cleaning-up:

- Section 2.2.1

Section 2.5 of RFC 6614 should apply to RADIUS over DTLS since a single port is used for all types of RADIUS codes.  ( I think the last bullet point in section 2.1 should be removed as well.)

- Section 5.1.1

This section references a requirement to receive RADIUS/UDP and RADIUS/DTLS on the same port, this is no longer a requirement.  Suggest cleaning up the text along the lines of:

" ...  Implementations that accept RADIUS/DTLS on the RADIUS/UDP port may find this recommendation difficult to implement in
   practice.  ... "

- Section 5.1.2

I still have a concern about the disambiguation recommendation since it relies upon a protocol field which is not in control of RADIUS, but it is rather in control of DTLS.  Its possible that int he future DTLS may choose to define a new extended handshake type that would use a different type code of 22.  This would introduce ambiguity and prevent this version of DTLS from being used with this mechanism.  It would be a better, more reliable design to have the disambiguation rely upon something that RADIUS had control over.   For example, define a RADIUS code type that encapsulates a RADIUS DTLS message.  

Additionally section 5.1.2 should clarify that it only applies to implementations that accept RADIUS/DTLS on the RADIUS/UDP port 

- Section 5.1.3 

Most of this section applies to implementations that accept RADIUS/DTLS on the RADIUS/UDP port.  THis section should clarify this.  I think the last 3 paragraphs are generic and can be moved to a a different section, such as 5.1.1.

- Section 9

We could request the same port as RADSEC.  Something like:

IANA is requested to assign a registered UDP  port number for RADIUS over DTLS.  The same values as for RADIUS over TLS (RFC6614) are requested.  That is, update the registry as follows:

      radius-dtls 2083/udp RADIUS over DTLS [RFCTBD]

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Apr 2013 11:32:28 +0300

Thanks Joe for detailed comments. Just few generic questions to the WG.

1) Do you agree with Joe's suggestion to use the same port as RADSEC:

2) Do you think Joe's concern on Section 5.1.2 "disambiguation recommendation"
   is something that need to be reconsidered.. 

- Jouni

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Apr 2013 11:24:41 -0400

Question: is the text Joe is concerned about still intended to be in the
draft?
That is, do we still want to specify running both over the same port as
an option?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Apr 2013 14:15:42 -0400

> That is, do we still want to specify running both over the same port as

  It's still in the draft, as a migration step.  The text in the draft
says that implementations should migrate to either using a dedicated
port, or to only allowing DTLS over the traditional ports.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Apr 2013 14:24:17 -0400

Ok.
I have no comments on Joe's issues.
I just wanted to make sure that it was not an editing artifact.

--Sam

---

From: Peter Deacon <[email-masked]>
Date: Mon, 29 Apr 2013 14:39:35 -0700 (Pacific Daylight Time)

> 	radius-dtls 2083/udp RADIUS over DTLS [RFCTBD]

Yep

>   is something that need to be reconsidered..

This does not seem to be difficult to mitigate against.  I think any of 
the following would be an improvement:

Either 4-byte or single byte header.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |          Session ID  (Issue #64)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | DTLS ...

or

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |          DTLS ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or

Removal of disambiguation.  DTLS implementations expected to use DTLS 
port.

Would prefer any of the above changes with a preference for removal of 
disambiguation however also willing to live with draft as-is.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 30 Apr 2013 08:45:56 -0400

> 	radius-dtls 2083/udp RADIUS over DTLS [RFCTBD]

  I'm OK with it.

>    is something that need to be reconsidered.. 

  I would prefer to avoid that.  The document makes it clear that this
is a temporary measure which should not be used long-term

  If the WG says the disambiguation is bad, then the preferred approach
would be to remove it entirely from the document.  There is precedent
for protocol disambiguation, but most protocols simply allocate a new port.

  The suggestion to encapsulate RADIUS inside of RADIUS opens the
document up *completely*.  It means we'd have to spend another 3 years
discussing the details.  And a better alternative exists: use a new port.

  I'm very opposed to RADIUS encapsulation.  I see nothing good coming
from it.  I'm similarly opposed to a "new" header for RADIUS over DTLS
over port 1812.  The resulting packet isn't RADIUS, and won't pass
RADIUS sanity checks for application-layer firewalls.

  If you're going to design a new protocol, the only reasonable thing to
do is to use a new port.

  Alan DeKok.