Ah, ok. Missed that, as old document was likely before setting up the registry’s was common.
- Bernie (from iPad) > On Oct 17, 2022, at 9:00 AM, [email protected] wrote: > >  > Re-, > > Point taken for the registry. > > For 4014bis, the issue is that there is no IANA registry for this and that > 4014 have only a frozen list of options with SHOULD and like. That text > should be fixed, hence > https://datatracker.ietf.org/doc/draft-boucadair-dhcwg-rfc4014-update/. > > Cheers, > Med > > De : Add <[email protected]> De la part de Bernie Volz > Envoyé : lundi 17 octobre 2022 14:49 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : [email protected]; Joe Clarke (jclarke) <[email protected]>; opsawg > <[email protected]>; ADD Mailing list <[email protected]>; [email protected] > Objet : Re: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for Encrypted DNS > > I do think it would be best to set up a registry and policy at the server as > to which it uses. > > —- > > I saw your 4014 bis, though technically you could have just requested IANA to > add your new radius attribute to the existing registry rather than doing the > bis document. > > In this bis document, the new table entry is a bit odd: > > 245.TBA1 | DHCPv4-Options | This-Document | > > As “this document” doesn’t define that new attribute, and not even TBA1 (that > is only reference). > > It may be better to just add an update to the Allowed Radius attributrs table > to the document that defines the new Radius attributes, rather than 2 > documents? > > - Bernie Volz > > > On Oct 17, 2022, at 8:08 AM, [email protected] wrote: > >  > Re-, > > Please see inline. > > Cheers, > Med > > De : Add <[email protected]> De la part de Bernie Volz > Envoyé : lundi 17 octobre 2022 13:42 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : [email protected]; Joe Clarke (jclarke) <[email protected]>; opsawg > <[email protected]>; ADD Mailing list <[email protected]>; [email protected] > Objet : Re: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for Encrypted DNS > > I was thinking more to put this restriction on the dhcp server, when it makes > use of the Radius attribute to respond to a client. > [Med] I think that this is similar to any guards used for consuming > conventional radius attributes. What differs in the proposed attribute is > just the encoding, not how this feeds the DHCP server logic, but … > > I have no issue with it being limited at configuration too, but the dhcp > server should also make sure only a limited set of options are sent to client. > [Med] … it is OK to add an explicit statement about a policy to control this > at the DHCP server side. > > > Leaving this wide open causes issues as it may be miss used to inject things > that really shouldn’t be. > [Med] OK. > > > Looking at it again, it is also unclear how a dhcp server is to use > information. For example, does the server use options from this information > before its own configuration or only if it has no configuration (I suspect > the former, as this is more client/request specific). > [Med] The logic at the server side is the same as how “conventional” RADIUS > attributes are consumed by DHCP server. > > And from RFC7037, there is > > 169 DNS-Server-IPv6-Address [RFC6911] > > Does this mean someone could now place the DNS server option into your new > Radius attribute instead of using this attribute to have the server map it to > the DHCP option? > [Med] The expectation is that this will be used to mimic future DHCPv6 > options, not those already governed by dedicated RADIUS attributes. > > > It seems to me that the reason for doing this is to handle the OPTION_V6_DNR > only, so maybe best to restrict just to this for now? Future documents could > add more to registry for options allowed. > [Med] I don’t have an objection to define a registry if you think this is > “safer”. Please advise. > > > - Bernie (from iPad) > > > > On Oct 17, 2022, at 2:15 AM, [email protected] wrote: > >  > Hi Bernie, > > Thank you for the feedback. > > I have considered a registry to declare the options that can be echoed in the > RADIUS attribute, but I then give it up because that list will be restricted > anyway by policy: > > RADIUS implementations may support a configuration parameter to > control the DHCP options that can be included in a DHCP*-Options > RADIUS attribute. > > Cheers, > Med > > De : Add <[email protected]> De la part de Bernie Volz > Envoyé : vendredi 14 octobre 2022 17:48 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : [email protected]; Joe Clarke (jclarke) <[email protected]>; opsawg > <[email protected]>; ADD Mailing list <[email protected]>; [email protected] > Objet : Re: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for Encrypted DNS > > Hi: > > Your github document is -03 and published is -03, so likely you want to make > it -04? > > As no dhcp options are being defined and they are just being encapsulated in > Radius attributes, not exactly sure how much the DHC wg can (or needs to) > comment? > > This basically changes things so you no longer have unique Radius attributes > that are mapped to DHCP options, but you just use the DHCP options directly. > This seems fine. (It does complicate the Radius configuration to handle DHCP > option configuration if you don’t want them to be hand encoded as octet data, > and many of the encoding/validation rules are not as consistent as we would > like, especially for older options.) > > The one concern for DHC wg may be to restrict the options that a DHCP server > can send out if these options are intended to be delivered to the client via > the dhcp server … for example, one would not want address or prefix > delegation options to be allowed. This might be something similar to > https://datatracker.ietf.org/doc/rfc6422/ which created a new registry for > the allowed DHCPv6 options that can be provided by a relay agent (in this > case encoded in the attributes). > > - Bernie Volz > > > > > On Oct 14, 2022, at 10:45 AM, [email protected] wrote: > > Hi Bernie, dhcwg, > > We received a comment during the WGLC of this draft that might lead us to > revisit the design you have reviewed recently. This alternative design > mirrors what we have done in 7037 (dhcwg) but with DHCP options included in > RADIUS. The candidate text is available at: > > https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt > > I'd appreciate if you can review this proposal and share any comments/issues > you may have. > > Thank you. > > Cheers, > Med > > > > > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : vendredi 14 octobre 2022 16:32 > À : 'Alan DeKok' <[email protected]> > Cc : Ben Schwartz <[email protected]>; Joe Clarke (jclarke) > <[email protected]>; opsawg <[email protected]>; [email protected]; > ADD Mailing list <[email protected]> > Objet : RE: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for > Encrypted DNS > > Re-, > > Works for me. Thanks. > > I will run this candidate version with dhcwg as well. > > Cheers, > Med > > -----Message d'origine----- > De : Alan DeKok <[email protected]> Envoyé : vendredi 14 > octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET > <[email protected]> Cc : Ben Schwartz > <[email protected]>; > Joe Abley <[email protected]>; Ben Schwartz > <[email protected]>; Joe Clarke (jclarke) > <[email protected]>; opsawg <[email protected]>; [email protected]; > ADD > Mailing list <[email protected]> Objet : Re: [Add] [OPSAWG] 🔔 WG LC: > RADIUS Extensions for Encrypted DNS > > > On Oct 14, 2022, at 5:47 AM, <[email protected]> > <[email protected]> wrote: > Let's try to exercise this approach and see if there are not > hidden complications vs. current design with known limitation. A > drafty text (not yet in the main draft) can be seen at: > https://github.com/boucadair/draft-ietf-opsawg-add-encrypted- > dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt > > Nits: > > Section 3: just drop the ASCII art. RFC 8044 makes it no longer > necessary. > > Section 3.1, 3.2, and 7.1: the data type should be "string" for > "opaque data" > > Other than that, it looks good on first read-through. > > The attributes should not be seen as opaque data by the RADIUS > server but it should understand the encoding of the enclosed > options. > The intended behavior should be called out, IMO. > > I would suggest saying something like "for ease of > administrator > configuration, the RADIUS server SHOULD expose the DHCP options > and > allow administrators to configure them, instead of requiring > them to > be entered as opaque data". > > That gets the best of both worlds. > > 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. > > _________________________________________________________________________________________________________________________ > > 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. > _________________________________________________________________________________________________________________________ > > 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. > _________________________________________________________________________________________________________________________ > > 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.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
