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

[[e-mail]]

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.

> 
> >
> > > (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. 

> 
> >
> > >
> > > (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.

> 
> >
> > > (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.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.