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

[[e-mail]]

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.