Subject: Re: [radext] New DTLS document

From: Jouni Korhonen <[email-masked]>
Date: Thu, 2 May 2013 11:26:08 +0300

On Apr 30, 2013, at 3:45 PM, Alan DeKok <[email-masked]> wrote:

> Jouni Korhonen wrote:
>> 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:
>> 
>> 	radius-dtls 2083/udp RADIUS over DTLS [RFCTBD]
> 
>  I'm OK with it.

So we have an agreement here.

>> 2) Do you think Joe's concern on Section 5.1.2 "disambiguation recommendation"
>>   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.
> 

My take is that we should not go for the RADIUS encapsulation or the new header.
I would be ok to remove Section 5.1.2 entirely. However, if WG wants to keep
Section 5.1.2 I would add a note there that it is intended to be a short term 
migration solution and can be turned off at some point of time. Implementations
and deployments are encouraged to switch to the RADIUS-DTLS port as soon as
possible. Would that be OK for the WG?

- Jouni

>  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 02 May 2013 12:04:07 -0400

Jouni Korhonen wrote:
> I would be ok to remove Section 5.1.2 entirely.

  Which means that the rest of the document needs to be updated, too.
It talks about accepting UDP and DTLS on the same port.  Section 5.1.2
is only *justification* for why that works.  The other sections say
*how* it's supposed to work.

  i.e. Deleting 5.1.2 means we'd have to delete more than half of
Section 3, too.

> However, if WG wants to keep

  I already added that in the latest rev.  See Section 3:

   This section describes how clients and servers should transition to
   DTLS.  There is a fair amount of discussion around this transition,
   as it is critical to get it correct.  We expect that once
   implementations have transitioned to RADIUS/DTLS, the text in this
   section will no longer be relevant.

  If we're just going to turn off UDP, we don't need any transition
path.  We just break the network, and let everyone figure out what to do.

  The whole point of the text in Section 3 is to document how the
transition path is handled.  Including (if so desired) accepting UDP and
DTLS on the same port.

  I can add duplicate text in Section 5.1.2.  But the idea is for people
to read the *entire* document, and act on it as a whole.

  Alan DeKok.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 2 May 2013 21:49:53 +0300

Hi,

>  i.e. Deleting 5.1.2 means we'd have to delete more than half of

That would be a side effect of this approach. However, most folks
(including me) seems to be okish keeping the current text as well.
So it would be Joe's voice that counts here now.

> to read the *entire* document, and act on it as a whole.

No need to duplicate. A pointer back to Section 3 would definitely 
suffice.

- Jouni

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 7 May 2013 00:45:54 +0000

> So it would be Joe's voice that counts here now.
[Joe]   So, I don't see any description as to how the transition mechanism allows transition to the new port.   Without this it seems its not really a transition mechanism but something that is intended to be around for a while.  So I think we either need to define how to actually transition or fix the mechanism.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 07 May 2013 10:33:47 -0700

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

I support using the same port as RADSEC.

>     is something that need to be reconsidered..

FWIW, I've also implemented RADSEC over DTLS and at least with my
implementation it would be hard to do both regular RADIUS and DTLS
on the same port. So I certainly prefer them to be different ports.

No other comments.

Stig

> - Jouni
>
>
> On Apr 22, 2013, at 8:32 AM, Joseph Salowey (jsalowey) <[email-masked]> wrote:
>
>> 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:
>>
>> On Apr 18, 2013, at 12:26 AM, Jouni Korhonen <[email-masked]> wrote:
>>
>>>
>>> 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
>>>
>>>
>>>
>>> On Apr 17, 2013, at 4:54 PM, Alan DeKok <[email-masked]> wrote:
>>>
>>>> http://tools.ietf.org/html/draft-ietf-radext-dtls-05
>>>>
>>>> Which addresses all of the open concerns.
>>>>
>>>> Alan DeKok.
>>>> _______________________________________________
>>>> radext mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/radext
>>>
>>> _______________________________________________
>>> radext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/radext
>>
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>