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

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

Hi Med, Alan,

Thanks.  I've requested LC on -09.

Regards,
Rob


> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: 09 February 2023 10:32
> 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
> 
> Re-,
> 
> Thanks Rob for the follow-up.
> 
> A new version with the proposed changes is now online: https://author-
> tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-09.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) <[e-mail]>
> > Envoyé : jeudi 9 février 2023 11:04
> > À : BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>;
> > Alan DeKok <[e-mail]>
> > Cc : [e-mail];
> > [e-mail]
> > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-
> > dns-07
> >
> > 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
> 
> 
> ________________________________________________________________
> _________________________________________________________
> 
> 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.