IETF Logo Mail Archive

Re: [OPSAWG] [Add] 🔔 WG LC: RADIUS Extensions for Encrypted DNS

Alan DeKok <aland@deployingradius.com> Fri, 14 October 2022 13:59 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3FEC1522A0; Fri, 14 Oct 2022 06:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTp7JVBl1xEe; Fri, 14 Oct 2022 06:59:55 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6E2C14F732; Fri, 14 Oct 2022 06:59:54 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 753BA6DA; Fri, 14 Oct 2022 13:59:51 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <18242_1665740874_6349304A_18242_265_4_dee5101db4734fcd8d7fa7f1f9a49030@orange.com>
Date: Fri, 14 Oct 2022 09:59:50 -0400
Cc: Ben Schwartz <bemasc@google.com>, Joe Abley <jabley@hopcount.ca>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, opsawg <opsawg@ietf.org>, "radext@ietf.org" <radext@ietf.org>, ADD Mailing list <add@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E60B6424-BE32-41FA-85F9-AFB07B3CA214@deployingradius.com>
References: <28766_1665646855_6347C107_28766_2_1_c61b294eae1742b4bfbf125d0fd0e92f@orange.com> <B6BBABE1-9194-4190-A84A-BA64889FC6E6@hopcount.ca> <CAHbrMsAsC0N2uNpFuiMYEiPgQQQzAwikuiTL0dWZoNhgcPRwNw@mail.gmail.com> <8F15B334-861A-432D-B42A-5C7C8D5FCCEB@deployingradius.com> <18242_1665740874_6349304A_18242_265_4_dee5101db4734fcd8d7fa7f1f9a49030@orange.com>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Ca4nGk1a1JYAeeXk6Pi60nDkHiY>
Subject: Re: [OPSAWG] [Add] 🔔 WG LC: RADIUS Extensions for Encrypted DNS
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2022 13:59:58 -0000

On Oct 14, 2022, at 5:47 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> Let's try to exercise this approach and see if there are not hidden complications vs. current design with known limitation. A drafty text (not yet in the main draft) can be seen at: https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt

  Nits:

Section 3: just drop the ASCII art.  RFC 8044 makes it no longer necessary.

Section 3.1, 3.2, and 7.1: the data type should be "string" for "opaque data"

  Other than that, it looks good on first read-through.
 
> The attributes should not be seen as opaque data by the RADIUS server but it should understand the encoding of the enclosed options. The intended behavior should be called out, IMO.

  I would suggest saying something like "for ease of administrator configuration, the RADIUS server SHOULD expose the DHCP options and allow administrators to configure them, instead of requiring them to be entered as opaque data".

  That gets the best of both worlds.

  Alan DeKok.

v2.29.0 | Report a Bug | By Email | System Status