Re: [dhcwg] [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Med, Alan,

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: 09 February 2023 09:02
> To: Rob Wilton (rwilton) <[e-mail]>; Alan DeKok
> <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
> 
> Hi Rob, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) <[e-mail]>
> > Envoyé : mercredi 8 février 2023 20:39
> > À : Alan DeKok <[e-mail]>
> > Cc : [e-mail];
> > [e-mail]
> > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-
> > dns-07
> >
> > Hi Alan,
> >
> > Sorry for the delay.  Please see inline ...
> >
> > > -----Original Message-----
> > > From: Alan DeKok <[e-mail]>
> > > Sent: 19 December 2022 17:13
> > > To: Rob Wilton (rwilton) <[e-mail]>
> > > Cc: [e-mail];
> > [e-mail]
> > > 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=[e-mail]> 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.
> >
> 
> [Med] OK. We can make this change:
> 
> OLD:
>    Absent any explicit configuration on the DHCP server, RADIUS
>    supplied data by means of DHCP*-Options Attributes take precedence
>    over any local configuration.
> 
> NEW:
>    RADIUS supplied data is specific configuration data that is
>    returned as a function of authentication and authorization checks.
>    As such, absent any explicit configuration on the DHCP server, RADIUS
>    supplied data by means of DHCP*-Options Attributes take precedence
>    over any local configuration.
[Rob Wilton (rwilton)] 

This is okay, but would probably prefer a slight tweak to the last sentence to:

   RADIUS supplied data is specific configuration data that is
   returned as a function of authentication and authorization checks.
   As such, absent any explicit configuration on the DHCP server, RADIUS
   supplied data by means of DHCP*-Options Attributes take precedence
   over any less specific or default local configuration.

But I'll leave this to the authors to decide.


> 
> >
> > >
> > > > (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.
> >
> >
> 
> [Med] We do already have the following:
> 
>    Note:  The 4096 bytes size limit was relaxed by other RFCs, e.g.,
>       [RFC7499] and [RFC7930].
> 
> Do we need to say more? Thanks.
[Rob Wilton (rwilton)] 

Nope.  I missed that you already state that.

> 
> >
> > >
> > > >
> > > > (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.
> >
> 
> [Med] We can echo the relevant part from 8415 here:
> 
> OLD:
>       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.
> 
> NEW:
>       This field contains a list of DHCPv6 options (Section 21 of
>       [RFC8415]).  Multiple instances of the same DHCPv6 option MAY be
>       included.  If an option appears multiple times, each instance is
>       considered separate and the data areas of the options MUST NOT be
>       concatenated or otherwise combined.  Consistent with Section 17 of
>       [RFC7227], this document does not impose any option order when
>       multiple options are present.
[Rob Wilton (rwilton)] 

Looks good.

Let me know when you have posted an updated draft.

Thanks,
Rob