Re: [radext] New DTLS document

Alan DeKok <aland@deployingradius.com> Thu, 02 May 2013 16:04 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC921F8FF2 for <radext@ietfa.amsl.com>; Thu, 2 May 2013 09:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.979
X-Spam-Level:
X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmL-HWUCArEa for <radext@ietfa.amsl.com>; Thu, 2 May 2013 09:04:10 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74D21F8FF1 for <radext@ietf.org>; Thu, 2 May 2013 09:04:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 60B912240E2B; Thu, 2 May 2013 18:04:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEKuNGn4dn50; Thu, 2 May 2013 18:04:09 +0200 (CEST)
Received: from Thor-2.local (bas1-ottawa11-1176121151.dsl.bell.ca [70.26.47.63]) by power.freeradius.org (Postfix) with ESMTPSA id 6B6BE2240297; Thu, 2 May 2013 18:04:08 +0200 (CEST)
Message-ID: <51828E77.9020303@deployingradius.com>
Date: Thu, 02 May 2013 12:04:07 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Jouni Korhonen <jouni.nospam@gmail.com>
References: <516EA97E.2000005@deployingradius.com> <C47910C2-BCEA-4DC2-A016-C98D67B62DD9@gmail.com> <A95B4818FD85874D8F16607F1AC7C628B4032E@xmb-rcd-x09.cisco.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <B43B810F-DBF3-4CCD-BFA0-494E10819D2A@gmail.com>
In-Reply-To: <B43B810F-DBF3-4CCD-BFA0-494E10819D2A@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: radext@ietf.org, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Subject: Re: [radext] New DTLS document
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2013 16:04:16 -0000

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
> 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?

  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.