IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 October 2022 20:19 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 24F0EC157B3B; Thu, 13 Oct 2022 13:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 P8f4Y8kI0VWw; Thu, 13 Oct 2022 13:19:33 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E76C157B34; Thu, 13 Oct 2022 13:19:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E387B18011; Thu, 13 Oct 2022 16:42:39 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OsIJf4yK7iXa; Thu, 13 Oct 2022 16:42:38 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 64C4E1800E; Thu, 13 Oct 2022 16:42:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1665693758; bh=+ldTUWhpUubRs6k+xWYdb/JNL99cA0c3ZX3vbuJGzi4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Vmf8L2XcWc7nGI5TxcH0EhXx0vF1WIrdGYpg6dOVKRxSdHR5IH3akIUOu62qhDNmm PNJr3vzTnjg1s9ihDqwIFp4W0lfueCQUX4y+uLrmF7ZgM8PX62mGxG2liABIml7pf9 Jom1F94QofZreR4J5bkt9DGbPDpX2HHCKW+5nVjvMEkHyenv9jsD8rvhLtDmzbu57K suiwu7oB3z/5Shx1hN+mcQDrVqxErdA5d1Ta2WFIJNtWum35gP12kjyph9kpqLtWmt xAWlLyD+397Yd75nmzY3w/+/gkSI0rE34k+03ilFnpNg4IrsnzzBibDEAVOHrDr8uC BaoCGwnE34AAQ==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6D13C58B; Thu, 13 Oct 2022 16:19:30 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alan DeKok <aland@deployingradius.com>, opsawg <opsawg@ietf.org>, radext@ietf.org, ADD Mailing list <add@ietf.org>
In-Reply-To: <8F15B334-861A-432D-B42A-5C7C8D5FCCEB@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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 13 Oct 2022 16:19:30 -0400
Message-ID: <23954.1665692370@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/3cQ6d3ONui_f1ux-gseuH_34hBY>
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: Thu, 13 Oct 2022 20:19:38 -0000

Alan DeKok <aland@deployingradius.com> wrote:
    > The only solution which entirely avoids the 253 octet limit is to just
    > define a DHCPv6-Options attribute in RADIUS.  It can carry a blob of
    > DHCPv6 options, encoded as DHCPv6 options.  This is behavior is
    > permitted by https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4:

If I understand you correctly, the DHCPv6 option bytes would just be sliced
up into 253 byte fragments, and then reassembled into DHCPv6 options.
The radius part need not respect the DHCPv6 option boundaries, but can fill
each DHCPv6-Options with as much as the fragment as fits.

    > Since the encoding is now DHCPv6 options, all limitations other than
    > the 4K RADIUS "maximum packet size" limitation disappear.  And many
    > RADIUS implementations support packets larger than 4K, so that limit is
    > not concrete either.  The specification defining DHCPv6-Options could
    > suggest that implementations SHOULD support 64K RADIUS packets.

Does Radius over TCP relax any of the 4K issue?


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

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