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

Alan DeKok <aland@deployingradius.com> Mon, 17 October 2022 12:51 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 52593C15258B; Mon, 17 Oct 2022 05:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 SvfgIYP6AZOk; Mon, 17 Oct 2022 05:51:12 -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 5F11AC152584; Mon, 17 Oct 2022 05:51:12 -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 A2F0C7B; Mon, 17 Oct 2022 12:51:09 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <0CEBD10A-6952-448B-92DC-AE5814475888@gmail.com>
Date: Mon, 17 Oct 2022 08:51:07 -0400
Cc: Mohamed Boucadair <mohamed.boucadair@orange.com>, dhcwg@ietf.org, "Joe Clarke (jclarke)" <jclarke@cisco.com>, opsawg <opsawg@ietf.org>, ADD Mailing list <add@ietf.org>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7042A3E-6A2D-4F73-B20B-EF51054153E8@deployingradius.com>
References: <14325_1665987354_634CF31A_14325_41_1_1dd1e0ff79424830b17e2ff0b468dbb7@orange.com> <0CEBD10A-6952-448B-92DC-AE5814475888@gmail.com>
To: Bernie Volz <bevolz@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/iK-AICV1f1oCDUblcpTZ87StCRY>
Subject: Re: [OPSAWG] [dhcwg] [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: Mon, 17 Oct 2022 12:51:18 -0000

On Oct 17, 2022, at 7:41 AM, Bernie Volz <bevolz@gmail.com> wrote:
> I was thinking more to put this restriction on the dhcp server, when it makes use of the Radius attribute to respond to a client. I have no issue with it being limited at configuration too, but the dhcp server should also make sure only a limited set of options are sent to client.
> 
> Leaving this wide open causes issues as it may be miss used to inject things that really shouldn’t be.

  I agree.  There should be a limited set of options which are allowed, perhaps via a registry.

> Looking at it again, it is also unclear how a dhcp server is to use information. For example, does the server use options from this information before its own configuration or only if it has no configuration (I suspect the former, as this is more client/request specific).

  That should be made explicit in the draft.  I don't have opinions either way, but your point makes sense.

> And from RFC7037, there is
> 
> 169        DNS-Server-IPv6-Address     [RFC6911]
> 
> Does this mean someone could now place the DNS server option into your new Radius attribute instead of using this attribute to have the server map it to the DHCP option?

  If it's allowed by the registry, presumably, yes.  RFFC 6911 says that those RADIUS attributes can appear multiple times.  So presumably it doesn't matter much if the DNS server information appears once in a RADIUS attribute, and separately in a DHCPv6-Options attribute.  They can all be added to the packets.

  i.e. if the administrator of the system configures something weird, the systems should just do what's asked.

  Anything past basic filtering is complex to define, and complex to implement.  And arguably doesn't have a lot of extra value.

  Alan DeKok.