Hi Alan, Sorry for the delay. Please see inline ...
> -----Original Message----- > From: Alan DeKok <al...@deployingradius.com> > Sent: 19 December 2022 17:13 > To: Rob Wilton (rwilton) <rwil...@cisco.com> > Cc: draft-ietf-opsawg-add-encrypted-dns....@ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07 > > On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton) > <rwilton=40cisco....@dmarc.ietf.org> wrote: > > It isn't really clear to me why some of the registries are needed, > > specifically > the ones in 8.4.1 and 8.4.2. Why not allow any v4 or v6 DHCP attribute to be > carried within the DHCPv6-Options or DHCPv4-Options field? > > The original intent of the document was to define a limited set of DHCP > options which could be carried in RADIUS. i.e. option X would map to RADIUS > attribute Y. After some discussion, this was deemed to be unworkable, and > changed to the current method. > > The previous limitations were still kept, however. > > While it is useful, I could see issues with allowing any DHCP option to be > transported in RADIUS. I'll have to dig deeper to get into details. [Rob Wilton (rwilton)] Okay. > > > > > (2) p 4, sec 3. DHCP Options RADIUS Attributes > > > > Absent any explicit configuration on the DHCP server, RADIUS supplied > > data by means of DHCP*-Options Attributes take precedence over any > > local configuration. > > > > This point may be worth discussing. Naturally, I would explicit > > configuration > to a network device to generally take precedent over implicitly learned > configuration from the network. > > I'm not sure which options are "implicitly learned" from the network. One > set > is configured in the device, and another is configured on a per-user / per- > session basis. This allows for sane defaults, with specific over-rides where > those are needed. > > If the options configured on the device always take precedence over the per- > session options (via RADIUS), then there isn't much point in sending > per-session > options. [Rob Wilton (rwilton)] To give a regular configuration example, if you were to enable the Ethernet auto-negotiation protocol but also explicitly configure an 10/100/1000 Ethernet interface to run at 100 Mb/s then I would expect the explicit client provided configuration to take precedence over negotiating the speed value. It sounds like, in what you describe, the configuration is effectively hierarchical. I.e., it is really because the RADIUS supplied configuration is more-specific that it takes precedence over the local configuration. If so, that is expected, but I think that it would be helpful to clarify the description to make that clear. > > > (3) p 6, sec 3.2. DHCPv4-Options Attribute > > > > Permitted DHCPv4 options in the DHCPv4-Options Attribute are > > maintained by IANA in the registry created in Section 8.4.2. > > > > Comparing this text to the description for v6, this description is silent on > whether multiple instances of the same DHCPv4 option MAY be included. > Should that be specified here? > > Likely, yes. The RADIUS attributes are simply carrying DHCP options, as if > they > were in a DHCP packet. So all of the DHCP rules about option handling should > apply here. [Rob Wilton (rwilton)] Okay. > > > > > (4) p 10, sec 7. Table of Attributes > > > > The following table provides a guide as what type of RADIUS packets > > that may contain these attributes, and in what quantity. > > > > Am I right that this is just a duplication of what is described in section > > 3? If > so, perhaps change "guide" to "informative guide" and include text to refer > back to the canonical definition in section 3. > > Sure. This table is traditional in RADIUS RFCs, so the text here mirrors > previous RADIUS RFCs. [Rob Wilton (rwilton)] Okay. > > > (8) p 3, sec 3. DHCP Options RADIUS Attributes > > > > These attributes use the "Long Extended Type" format in order to > > permit the transport of attributes encapsulating more than 253 octets > > of data. DHCP options that can be included in the DHCP*-Options > > RADIUS attributes are limited by the maximum packet size of 4096 > > bytes. In order to accommodate deployments with large options, > > implementations are RECOMMENDED to support a packet size up to 65535 > > bytes. > > > > I didn't find this text clear. E.g., limit is 4k but should support up to > > 64K. > Which implementations should support larger packet sizes? Is this RADIUS > implementations? > > It's a limitation of RADIUS. Everything RADIUS has to support 4K packets. > Later RFCs allow for 64K packets. [Rob Wilton (rwilton)] Okay. If this will be obvious to everyone implementing/deploying RADIUS then fine, otherwise it might be worth including an informative reference to the RFC that increases the limit to 64K. > > > > > (9) p 5, sec 3.1. DHCPv6-Options Attribute > > > > This field contains a list of DHCPv6 options. Multiple instances > > of the same DHCPv6 option MAY be included. Consistent with > > Section 17 of [RFC7227], this document does not impose any option > > order when multiple options are present. > > > > Is there any requirement to merge multiple instances of options together, > presumably they are logically just concatenated today. > > The rules for DHCP options processing should apply. [Rob Wilton (rwilton)] Okay. Should that be stated here, or at least made consistent with the v4 description that has been updated to: | This field contains a list of DHCPv4 options. Multiple instances | of the same DHCPv4 option MAY be included, especially for | concatenation-requiring options that exceed the maximum DHCPv4 | option size of 255 octets. The mechanism specified in [RFC3396] | MUST be used for splitting and concatenating the instances of a | concatenation-requiring option. > > > (12) p 8, sec 5. Applicability to Encrypted DNS Provisioning > > > > Figure 1: An Example of RADIUS IPv6 Encrypted DNS Exchange > > > > As a minor comment, I wonder whether it would be helpful to also include > RADIUS client in the NAS box description? > > Yes. > > > > > (13) p 12, sec 8.4.1. DHCPv6 > > > > IANA is requested to create a new sub-registry entitled "DHCPv6 > > Options Permitted in the RADIUS DHCPv6-Options Attribute" in the > > "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry > > [DHCP-RADIUS]. > > > > Do we need to define the definition of columns for this (and the v4 > equivalent) registries. E.g., do the values need to match another registry? > > Perhaps just names? It would be good to avoid duplicating multiple columns, > as they could get out of sync. The changes that you have made for -08 for this seem fine. Thanks, Rob > > Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
