Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
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, mohamed.boucad...@orange.com 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 De la part de Bernie Volz > Envoyé : lundi 17 octobre 2022 14:49 > À : BOUCADAIR Mohamed INNOV/NET > Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg > ; ADD Mailing list ; rad...@ietf.org > 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, mohamed.boucad...@orange.com wrote: > > > Re-, > > Please see inline. > > Cheers, > Med > > De : Add De la part de Bernie Volz > Envoyé : lundi 17 octobre 2022 13:42 > À : BOUCADAIR Mohamed INNOV/NET > Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg > ; ADD Mailing list ; rad...@ietf.org > 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 > > 169DNS-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, mohamed.boucad...@orange.com 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 De la part de Bernie Volz > Envoyé : vendredi 14 octobre 2022 17:48 > À : BOUCADAIR Mohamed INNOV/NET > Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg > ; ADD Mailing list ; rad...@ietf.org > Objet : Re: [Add] [OPSAWG] WG LC
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
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 De la part de Bernie Volz Envoyé : lundi 17 octobre 2022 14:49 À : BOUCADAIR Mohamed INNOV/NET Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg ; ADD Mailing list ; rad...@ietf.org 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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Re-, Please see inline. Cheers, Med De : Add mailto:add-boun...@ietf.org>> De la part de Bernie Volz Envoyé : lundi 17 octobre 2022 13:42 À : BOUCADAIR Mohamed INNOV/NET mailto:mohamed.boucad...@orange.com>> Cc : dh...@ietf.org<mailto:dh...@ietf.org>; Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; opsawg mailto:opsawg@ietf.org>>; ADD Mailing list mailto:a...@ietf.org>>; rad...@ietf.org<mailto:rad...@ietf.org> 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 169DNS-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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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 mailto:add-boun...@ietf.org>> De la part de Bernie Volz Envoyé : vendredi 14 octobre 2022 17:48 À : BOUCADAIR Mohamed INNOV/NET mailto:mohamed.boucad...@orange.com>> Cc : dh...@ietf.org<mailto:dh...@ietf.org>; Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; opsawg mailto:opsawg@ietf.org>>; ADD Mailing list mailto:a...@ietf.org>>; rad...@ietf.org<mailto:rad...@ietf.org> 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
Re: [OPSAWG] [Add] 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, mohamed.boucad...@orange.com wrote: > > > Re-, > > Please see inline. > > Cheers, > Med > > De : Add De la part de Bernie Volz > Envoyé : lundi 17 octobre 2022 13:42 > À : BOUCADAIR Mohamed INNOV/NET > Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg > ; ADD Mailing list ; rad...@ietf.org > 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 > > 169DNS-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, mohamed.boucad...@orange.com 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 De la part de Bernie Volz > Envoyé : vendredi 14 octobre 2022 17:48 > À : BOUCADAIR Mohamed INNOV/NET > Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg > ; ADD Mailing list ; rad...@ietf.org > 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 s
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Re-, Please see inline. Cheers, Med De : Add De la part de Bernie Volz Envoyé : lundi 17 octobre 2022 13:42 À : BOUCADAIR Mohamed INNOV/NET Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg ; ADD Mailing list ; rad...@ietf.org 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 169DNS-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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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 mailto:add-boun...@ietf.org>> De la part de Bernie Volz Envoyé : vendredi 14 octobre 2022 17:48 À : BOUCADAIR Mohamed INNOV/NET mailto:mohamed.boucad...@orange.com>> Cc : dh...@ietf.org<mailto:dh...@ietf.org>; Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; opsawg mailto:opsawg@ietf.org>>; ADD Mailing list mailto:a...@ietf.org>>; rad...@ietf.org<mailto:rad...@ietf.org> 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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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
Re: [OPSAWG] [Add] 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. 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. Leaving this wide open causes issues as it may be miss used to inject things that really shouldn’t be. 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). And from RFC7037, there is 169DNS-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? 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. - Bernie (from iPad) > On Oct 17, 2022, at 2:15 AM, mohamed.boucad...@orange.com 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 De la part de Bernie Volz > Envoyé : vendredi 14 octobre 2022 17:48 > À : BOUCADAIR Mohamed INNOV/NET > Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg > ; ADD Mailing list ; rad...@ietf.org > 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, mohamed.boucad...@orange.com 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' > Cc : Ben Schwartz ; Joe Clarke (jclarke) > ; opsawg ; rad...@ietf.org; > ADD Mailing list > 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 Envoyé : vendredi 14 > octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET > Cc : Ben Schwartz > ; > Joe Abley ; Ben Schwartz > ; Joe Clarke (jclarke) > ; opsawg ; rad...@ietf.org; > ADD > Mailing list Objet : Re: [Add] [OPSAWG] WG LC: > RADIUS Extensions for Encrypted DNS > > > On Oct 14, 2022, at 5:47 AM, > wrote: > Let's try to exercise this approach and see if there are not > hidden c
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
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 De la part de Bernie Volz Envoyé : vendredi 14 octobre 2022 17:48 À : BOUCADAIR Mohamed INNOV/NET Cc : dh...@ietf.org; Joe Clarke (jclarke) ; opsawg ; ADD Mailing list ; rad...@ietf.org 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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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' mailto:al...@deployingradius.com>> Cc : Ben Schwartz mailto:bem...@google.com>>; Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; opsawg mailto:opsawg@ietf.org>>; rad...@ietf.org<mailto:rad...@ietf.org>; ADD Mailing list mailto:a...@ietf.org>> 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 mailto:al...@deployingradius.com>> Envoyé : vendredi 14 octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET mailto:mohamed.boucad...@orange.com>> Cc : Ben Schwartz mailto:bem...@google.com>>; Joe Abley mailto:jab...@hopcount.ca>>; Ben Schwartz mailto:bemasc=40google@dmarc.ietf.org>>; Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; opsawg mailto:opsawg@ietf.org>>; rad...@ietf.org<mailto:rad...@ietf.org>; ADD Mailing list mailto:a...@ietf.org>> Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for Encrypted DNS On Oct 14, 2022, at 5:47 AM, mailto:mohamed.boucad...@orange.com>> mailto:mohamed.boucad...@orange.com>> 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 d
Re: [OPSAWG] [Add] 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, mohamed.boucad...@orange.com 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' >> Cc : Ben Schwartz ; Joe Clarke (jclarke) >> ; opsawg ; rad...@ietf.org; >> ADD Mailing list >> 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 Envoyé : vendredi 14 >>> octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET >>> Cc : Ben Schwartz >> ; >>> Joe Abley ; Ben Schwartz >>> ; Joe Clarke (jclarke) >>> ; opsawg ; rad...@ietf.org; >> ADD >>> Mailing list Objet : Re: [Add] [OPSAWG] WG LC: >>> RADIUS Extensions for Encrypted DNS >>> >>> >>> On Oct 14, 2022, at 5:47 AM, >>> 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. > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
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' > Cc : Ben Schwartz ; Joe Clarke (jclarke) > ; opsawg ; rad...@ietf.org; > ADD Mailing list > 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 Envoyé : vendredi 14 > > octobre 2022 16:00 À : BOUCADAIR Mohamed INNOV/NET > > Cc : Ben Schwartz > ; > > Joe Abley ; Ben Schwartz > > ; Joe Clarke (jclarke) > > ; opsawg ; rad...@ietf.org; > ADD > > Mailing list Objet : Re: [Add] [OPSAWG] WG LC: > > RADIUS Extensions for Encrypted DNS > > > > > > On Oct 14, 2022, at 5:47 AM, > > 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] 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 > Envoyé : vendredi 14 octobre 2022 16:00 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Ben Schwartz ; Joe Abley > ; Ben Schwartz > ; Joe Clarke (jclarke) > ; opsawg ; rad...@ietf.org; > ADD Mailing list > Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for > Encrypted DNS > > > On Oct 14, 2022, at 5:47 AM, > 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 14, 2022, at 5:47 AM, 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Re-, Thanks for the feedback. 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 A diff is also available at: https://www.ietf.org/rfcdiff?url1=draft-ietf-opsawg-add-encrypted-dns=https://raw.githubusercontent.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/master/draft-ietf-opsawg-add-encrypted-dns-encap.txt 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. For the case of RA-triggered authorization process, some adaptation is needed as the encoding is a little but distinct vs. DHCPv6. The mapping should also be explicated. Cheers, Med > -Message d'origine- > De : Alan DeKok > Envoyé : jeudi 13 octobre 2022 17:16 > À : Ben Schwartz > Cc : Joe Abley ; BOUCADAIR Mohamed INNOV/NET > ; Ben Schwartz > ; Joe Clarke (jclarke) > ; opsawg ; rad...@ietf.org; > ADD Mailing list > Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for > Encrypted DNS > > On Oct 13, 2022, at 10:50 AM, Ben Schwartz > wrote: > > Even if longer SvcParams aren't useful in DNR, creating an > encoding that can't carry them introduces a serious compatibility > problem for systems that copy between SVCB, DNR, and RADIUS. What > is such a tool supposed to do when a valid SVCB record or DNR > option is unrepresentable in RADIUS? What is a naive operator to > do, faced with this error message? > > The traditional RADIUS solution for encoding data which can't > fit into an attribute is one of (a) truncation, or (b) dropping > the attribute entirely. The standards are silent on this issue, > so the behavior is entirely implementation-defined. > > As for this issue, it may be best to avoid it entirely with > careful design, so that it's not possible for implementations to > run into the problem. > > > The only solution which entirely avoids the 253 octet limit is > to just define a DHCPv6-Options attribute in RADIUS. It can carry > a blob of DHCPv6 options, encoded as DHCPv6 options. This is > behavior is permitted by https://www.rfc- > editor.org/rfc/rfc6158#section-3.2.4: > > Another exception to the recommendation against complex types > is for > types that can be treated as opaque data by the RADIUS > server. > > So just define a DHCPv6-Options attribute from the 245.X space. > Allow it to contain any DHCPv6 option. Suggest that the switch / > RADIUS client send the options in a DHCPv6 packet. And then it > can carry the options needed here. > > Since the encoding is now DHCPv6 options, all limitations other > than the 4K RADIUS "maximum packet size" limitation disappear. > And many RADIUS implementations support packets larger than 4K, so > that limit is not concrete either. The specification defining > DHCPv6-Options could suggest that implementations SHOULD support > 64K RADIUS packets. > > 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 13, 2022, at 4:19 PM, Michael Richardson wrote: > If I understand you correctly, the DHCPv6 option bytes would just be sliced > up into 253 byte fragments, and then reassembled into DHCPv6 options. Largely, yes. > The radius part need not respect the DHCPv6 option boundaries, but can fill > each DHCPv6-Options with as much as the fragment as fits. Yes. Similar things happen already with EAP packets. These are ~1K or more. RADIUS is just a transport, so "EAP goes in" and "EAP comes out". The EAP contents are unmodified. > Does Radius over TCP relax any of the 4K issue? No. But it avoids fragmentation of UDP packets. Which is positive. And RADIUS/UDP needs to die anyways, so Taking a quick look, nothing else in RADIUS mandates support for longer than 4K packets. However, I believe that many implementations are happy to accept longer packets. i.e. it's 2022, I think that software can easily handle 64K buffers for network protocols. There's also RFC 7499 which supports fragmentation of CoA packets. Perhaps a similar method could be used here, if required? Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Alan DeKok wrote: > The only solution which entirely avoids the 253 octet limit is to just > define a DHCPv6-Options attribute in RADIUS. It can carry a blob of > DHCPv6 options, encoded as DHCPv6 options. This is behavior is > permitted by https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4: If I understand you correctly, the DHCPv6 option bytes would just be sliced up into 253 byte fragments, and then reassembled into DHCPv6 options. The radius part need not respect the DHCPv6 option boundaries, but can fill each DHCPv6-Options with as much as the fragment as fits. > Since the encoding is now DHCPv6 options, all limitations other than > the 4K RADIUS "maximum packet size" limitation disappear. And many > RADIUS implementations support packets larger than 4K, so that limit is > not concrete either. The specification defining DHCPv6-Options could > suggest that implementations SHOULD support 64K RADIUS packets. Does Radius over TCP relax any of the 4K issue? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 13, 2022, at 10:50 AM, Ben Schwartz wrote: > Even if longer SvcParams aren't useful in DNR, creating an encoding that > can't carry them introduces a serious compatibility problem for systems that > copy between SVCB, DNR, and RADIUS. What is such a tool supposed to do when > a valid SVCB record or DNR option is unrepresentable in RADIUS? What is a > naive operator to do, faced with this error message? The traditional RADIUS solution for encoding data which can't fit into an attribute is one of (a) truncation, or (b) dropping the attribute entirely. The standards are silent on this issue, so the behavior is entirely implementation-defined. As for this issue, it may be best to avoid it entirely with careful design, so that it's not possible for implementations to run into the problem. The only solution which entirely avoids the 253 octet limit is to just define a DHCPv6-Options attribute in RADIUS. It can carry a blob of DHCPv6 options, encoded as DHCPv6 options. This is behavior is permitted by https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4: Another exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. So just define a DHCPv6-Options attribute from the 245.X space. Allow it to contain any DHCPv6 option. Suggest that the switch / RADIUS client send the options in a DHCPv6 packet. And then it can carry the options needed here. Since the encoding is now DHCPv6 options, all limitations other than the 4K RADIUS "maximum packet size" limitation disappear. And many RADIUS implementations support packets larger than 4K, so that limit is not concrete either. The specification defining DHCPv6-Options could suggest that implementations SHOULD support 64K RADIUS packets. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Thu, Oct 13, 2022 at 7:51 AM Ben Schwartz wrote: > I don't think we need to determine whether ECH is relevant for the DNR use > case. Indeed, ECH as presently specified will generally fit inside the > 250-octet limit. My point is that we are setting ourselves up for a very > painful compatibility challenge if longer SvcParams come into use in the > future. I can certainly imagine longer parameters (e.g. signed objects > with certificate chains) that might be useful in DNR. > > Even if longer SvcParams aren't useful in DNR, creating an encoding that > can't carry them introduces a serious compatibility problem for systems > that copy between SVCB, DNR, and RADIUS. What is such a tool supposed to > do when a valid SVCB record or DNR option is unrepresentable in RADIUS? > What is a naive operator to do, faced with this error message? > > I understand that we can't eliminate this problem, due to the 4K limit, > but I think it's worth avoiding it as much as we can, even if it costs us a > page or two of standards text. > +1 --Ben > > On Thu, Oct 13, 2022 at 9:03 AM Joe Abley wrote: > >> Hi Mohamed, >> >> I may well have missed some nuance in the discussion that came before, >> but I found this comment interesting: >> >> On Oct 13, 2022, at 03:41, mohamed.boucad...@orange.com wrote: >> >> This specification targets typical broadband services in which the use of >> ECH is not relevant. It does not make sense for ISPs to be hosting multiple >> domains on the same IP address as the encrypted DNS resolver. >> >> >> Can you say why? >> >> If an operator has invested in infrasructure designed to be able to >> handle TLS and HTTP at high volumes with high availability, does it not >> seem possible that they would seek to reuse that general TLS/HTTP >> infrastructure for multiple purposes? If ECH is relevant in other services >> carried over HTTPS, why is it definitively not relevant for this one? >> >> >> Joe >> -- >> Add mailing list >> a...@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
I don't think we need to determine whether ECH is relevant for the DNR use case. Indeed, ECH as presently specified will generally fit inside the 250-octet limit. My point is that we are setting ourselves up for a very painful compatibility challenge if longer SvcParams come into use in the future. I can certainly imagine longer parameters (e.g. signed objects with certificate chains) that might be useful in DNR. Even if longer SvcParams aren't useful in DNR, creating an encoding that can't carry them introduces a serious compatibility problem for systems that copy between SVCB, DNR, and RADIUS. What is such a tool supposed to do when a valid SVCB record or DNR option is unrepresentable in RADIUS? What is a naive operator to do, faced with this error message? I understand that we can't eliminate this problem, due to the 4K limit, but I think it's worth avoiding it as much as we can, even if it costs us a page or two of standards text. --Ben On Thu, Oct 13, 2022 at 9:03 AM Joe Abley wrote: > Hi Mohamed, > > I may well have missed some nuance in the discussion that came before, but > I found this comment interesting: > > On Oct 13, 2022, at 03:41, mohamed.boucad...@orange.com wrote: > > This specification targets typical broadband services in which the use of > ECH is not relevant. It does not make sense for ISPs to be hosting multiple > domains on the same IP address as the encrypted DNS resolver. > > > Can you say why? > > If an operator has invested in infrasructure designed to be able to handle > TLS and HTTP at high volumes with high availability, does it not seem > possible that they would seek to reuse that general TLS/HTTP infrastructure > for multiple purposes? If ECH is relevant in other services carried over > HTTPS, why is it definitively not relevant for this one? > > > Joe > -- > Add mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/add > smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Hi Mohamed, I may well have missed some nuance in the discussion that came before, but I found this comment interesting: On Oct 13, 2022, at 03:41, mohamed.boucad...@orange.com wrote: > This specification targets typical broadband services in which the use of ECH > is not relevant. It does not make sense for ISPs to be hosting multiple > domains on the same IP address as the encrypted DNS resolver. Can you say why? If an operator has invested in infrasructure designed to be able to handle TLS and HTTP at high volumes with high availability, does it not seem possible that they would seek to reuse that general TLS/HTTP infrastructure for multiple purposes? If ECH is relevant in other services carried over HTTPS, why is it definitively not relevant for this one? Joe___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
For an operator standpoint, it seems this point may not be clear enough in the draft and at the very least would likely benefit from some text to call out the limitation. Joe From: mohamed.boucad...@orange.com Date: Thursday, October 13, 2022 at 3:41 AM To: Ben Schwartz , Alan DeKok Cc: Joe Clarke (jclarke) , opsawg@ietf.org , rad...@ietf.org , a...@ietf.org Subject: RE: [Add] [OPSAWG] WG LC: RADIUS Extensions for Encrypted DNS Hi Ben, all, This specification targets typical broadband services in which the use of ECH is not relevant. It does not make sense for ISPs to be hosting multiple domains on the same IP address as the encrypted DNS resolver. Cheers, Med De : Add De la part de Ben Schwartz Envoyé : mercredi 12 octobre 2022 19:54 À : Alan DeKok Cc : Joe Clarke (jclarke) ; opsawg@ietf.org; rad...@ietf.org; a...@ietf.org Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for Encrypted DNS A practical limit of around 4000 octets for SvcParams seems likely to be fine. A hard limit of 250 octets has a real chance of becoming a practical problem. I would encourage you to reconsider the format. As a concrete example, SvcParams are used to deliver public keys for ECH. Currently, only elliptic-curve keys are used, but if a future iteration relied on RSA public keys, they would not fit within this limit. On Wed, Oct 12, 2022 at 1:41 PM Alan DeKok mailto:al...@deployingradius.com>> wrote: On Oct 12, 2022, at 1:32 PM, Ben Schwartz mailto:40google@dmarc.ietf.org>> wrote: > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This is a > problem, since it is meant to hold a SvcParams object that is allowed to be > much larger (up to ~65000 octets in principle). The length is less than 253 octets, as it is encapsulated inside of another attribute "wrapper". So the practical limit is probably 250 or less. RADIUS provides for encoding more than 253 octets in an attribute. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 However, this capability exists only for "top level" attributes, and cannot be used here. Further, RADIUS packets are generally limited to 4K octets total. So even if the limits on this attribute are removed, then there's still a practical limit of around 4000 octets. 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Re-, Please see inline. Cheers, Med > -Message d'origine- > De : Alan DeKok > Envoyé : jeudi 13 octobre 2022 13:40 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Ben Schwartz ; Joe Clarke (jclarke) > ; opsawg@ietf.org; rad...@ietf.org; > a...@ietf.org > Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for > Encrypted DNS > > On Oct 13, 2022, at 4:11 AM, mohamed.boucad...@orange.com wrote: > > > > Hi Alan, all, > > > > FYI, we do already have the following in the draft to pass > RADIUS attributes in DHCPv6: > > > > In deployments where the NAS behaves as a DHCPv6 relay agent, > the > > procedure discussed in Section 3 of [RFC7037] can be followed. > To > > that aim, Section 6.3 updates the "RADIUS Attributes Permitted > in > > DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]). > > I was thinking of the other way around: allowing DHCPv6 options > inside of a RADIUS attribute. [Med] Yes, I got that. But I wanted to highlight that, as we are already allowing to encapsulate radius attributes in dhcp, if we encapsulate dhcp in radius, then for the case in 7037, we will end up with dhcp_option(radius(dhcp_option)) encapsulation. > > > For the typical target deployment in the draft, I don' think we > have a valid case for long data. That's said, we may include a > provision to allow for multiple TLVs; each carrying self-contained > key=value data. > > If that's the target deployment, then that works. I'd suggest > updating the draft to explicitly mention this limitation, and > describe why it's acceptable. [Med] Yes, that's exactly what I have in mind. > > I'd also suggest changing the RADIUS attribute space from 241.X > to 245.X. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 [Med] Agree. Will fix that. Thanks. > > With 241.X, the maximum amount of data which can be carried is > 252 octets. This space has to encapsulate all child attributes, > including headers and contents. Which means that each individual > child attribute can carry much less than 253 octets. > > With 245.X, the maximum amount of data which can be carried is > limited only by the RADIUS packet length. Each child attribute > can then carry a full 253 octets of data. And there are no limits > on the number of child attributes which ca be carried. > > 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 13, 2022, at 4:11 AM, mohamed.boucad...@orange.com wrote: > > Hi Alan, all, > > FYI, we do already have the following in the draft to pass RADIUS attributes > in DHCPv6: > > In deployments where the NAS behaves as a DHCPv6 relay agent, the > procedure discussed in Section 3 of [RFC7037] can be followed. To > that aim, Section 6.3 updates the "RADIUS Attributes Permitted in > DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]). I was thinking of the other way around: allowing DHCPv6 options inside of a RADIUS attribute. > For the typical target deployment in the draft, I don' think we have a valid > case for long data. That's said, we may include a provision to allow for > multiple TLVs; each carrying self-contained key=value data. If that's the target deployment, then that works. I'd suggest updating the draft to explicitly mention this limitation, and describe why it's acceptable. I'd also suggest changing the RADIUS attribute space from 241.X to 245.X. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 With 241.X, the maximum amount of data which can be carried is 252 octets. This space has to encapsulate all child attributes, including headers and contents. Which means that each individual child attribute can carry much less than 253 octets. With 245.X, the maximum amount of data which can be carried is limited only by the RADIUS packet length. Each child attribute can then carry a full 253 octets of data. And there are no limits on the number of child attributes which ca be carried. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Hi Alan, all, FYI, we do already have the following in the draft to pass RADIUS attributes in DHCPv6: In deployments where the NAS behaves as a DHCPv6 relay agent, the procedure discussed in Section 3 of [RFC7037] can be followed. To that aim, Section 6.3 updates the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]). For the typical target deployment in the draft, I don' think we have a valid case for long data. That's said, we may include a provision to allow for multiple TLVs; each carrying self-contained key=value data. Cheers, Med > -Message d'origine- > De : Add De la part de Alan DeKok > Envoyé : mercredi 12 octobre 2022 20:11 > À : Ben Schwartz > Cc : Joe Clarke (jclarke) ; opsawg@ietf.org; > rad...@ietf.org; a...@ietf.org > Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for > Encrypted DNS > > On Oct 12, 2022, at 1:53 PM, Ben Schwartz > wrote: > > > > A practical limit of around 4000 octets for SvcParams seems > likely to be fine. A hard limit of 250 octets has a real chance > of becoming a practical problem. I would encourage you to > reconsider the format. > > There are a number of limitations which all have to be addressed > in order for any solution to work. :( > > This specification requires "grouped" data, which generally > means TLVs in RADIUS. However, it also requires "long" data, > which is forbidden to be used in TLVs by https://www.rfc- > editor.org/rfc/rfc8044#section-3.16 > > As the author of RFC 8044, I can say that there are good reasons > for that prohibition. I can also say that there are good reasons > why the prohibited functionality is needed by this standard. > > I'm not sure there are any perfect solutions. There's only > varying amounts of holding your nose, and going with something > which is the lesser of two evils. > > Off of the top of my head, one approach is to simply give up on > transporting the DHCPv6 data as RADIUS attributes, and instead > just define a DHCPv6-Options attribute in RADIUS, which carries > raw DHCPv6 options. This attribute could carry ~4K of data, and > be in a format which complies with RFC 8044. > > That would solve the problem not only for this use-case, but for > any future one, too. Just define the DHCPv6 option, and then say > "carry it in RADIUS attribute DHCPv6-Options" > > That makes it difficult for administrators to configure, as the > RADIUS configuration now has to carry "raw" DHCPv6 data. But... > it's RADIUS. That's the least of its ugliness. > > > There's already something similar in DHCPv4: > https://datatracker.ietf.org/doc/html/rfc4014 i.e. DHCPv4 carries > RADIUS attributes. So there's reasonable precedent. > > Alan DeKok. > > -- > Add mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/add _ 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Hi Ben, all, This specification targets typical broadband services in which the use of ECH is not relevant. It does not make sense for ISPs to be hosting multiple domains on the same IP address as the encrypted DNS resolver. Cheers, Med De : Add De la part de Ben Schwartz Envoyé : mercredi 12 octobre 2022 19:54 À : Alan DeKok Cc : Joe Clarke (jclarke) ; opsawg@ietf.org; rad...@ietf.org; a...@ietf.org Objet : Re: [Add] [OPSAWG] WG LC: RADIUS Extensions for Encrypted DNS A practical limit of around 4000 octets for SvcParams seems likely to be fine. A hard limit of 250 octets has a real chance of becoming a practical problem. I would encourage you to reconsider the format. As a concrete example, SvcParams are used to deliver public keys for ECH. Currently, only elliptic-curve keys are used, but if a future iteration relied on RSA public keys, they would not fit within this limit. On Wed, Oct 12, 2022 at 1:41 PM Alan DeKok mailto:al...@deployingradius.com>> wrote: On Oct 12, 2022, at 1:32 PM, Ben Schwartz mailto:40google@dmarc.ietf.org>> wrote: > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This is a > problem, since it is meant to hold a SvcParams object that is allowed to be > much larger (up to ~65000 octets in principle). The length is less than 253 octets, as it is encapsulated inside of another attribute "wrapper". So the practical limit is probably 250 or less. RADIUS provides for encoding more than 253 octets in an attribute. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 However, this capability exists only for "top level" attributes, and cannot be used here. Further, RADIUS packets are generally limited to 4K octets total. So even if the limits on this attribute are removed, then there's still a practical limit of around 4000 octets. 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 12, 2022, at 1:53 PM, Ben Schwartz wrote: > > A practical limit of around 4000 octets for SvcParams seems likely to be > fine. A hard limit of 250 octets has a real chance of becoming a practical > problem. I would encourage you to reconsider the format. There are a number of limitations which all have to be addressed in order for any solution to work. :( This specification requires "grouped" data, which generally means TLVs in RADIUS. However, it also requires "long" data, which is forbidden to be used in TLVs by https://www.rfc-editor.org/rfc/rfc8044#section-3.16 As the author of RFC 8044, I can say that there are good reasons for that prohibition. I can also say that there are good reasons why the prohibited functionality is needed by this standard. I'm not sure there are any perfect solutions. There's only varying amounts of holding your nose, and going with something which is the lesser of two evils. Off of the top of my head, one approach is to simply give up on transporting the DHCPv6 data as RADIUS attributes, and instead just define a DHCPv6-Options attribute in RADIUS, which carries raw DHCPv6 options. This attribute could carry ~4K of data, and be in a format which complies with RFC 8044. That would solve the problem not only for this use-case, but for any future one, too. Just define the DHCPv6 option, and then say "carry it in RADIUS attribute DHCPv6-Options" That makes it difficult for administrators to configure, as the RADIUS configuration now has to carry "raw" DHCPv6 data. But... it's RADIUS. That's the least of its ugliness. There's already something similar in DHCPv4: https://datatracker.ietf.org/doc/html/rfc4014 i.e. DHCPv4 carries RADIUS attributes. So there's reasonable precedent. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
A practical limit of around 4000 octets for SvcParams seems likely to be fine. A hard limit of 250 octets has a real chance of becoming a practical problem. I would encourage you to reconsider the format. As a concrete example, SvcParams are used to deliver public keys for ECH. Currently, only elliptic-curve keys are used, but if a future iteration relied on RSA public keys, they would not fit within this limit. On Wed, Oct 12, 2022 at 1:41 PM Alan DeKok wrote: > On Oct 12, 2022, at 1:32 PM, Ben Schwartz 40google@dmarc.ietf.org> wrote: > > > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This > is a problem, since it is meant to hold a SvcParams object that is allowed > to be much larger (up to ~65000 octets in principle). > > The length is less than 253 octets, as it is encapsulated inside of > another attribute "wrapper". So the practical limit is probably 250 or > less. > > RADIUS provides for encoding more than 253 octets in an attribute. See > https://www.rfc-editor.org/rfc/rfc8044#section-3.16 > > However, this capability exists only for "top level" attributes, and > cannot be used here. > > Further, RADIUS packets are generally limited to 4K octets total. So > even if the limits on this attribute are removed, then there's still a > practical limit of around 4000 octets. > > Alan DeKok. > > smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
Among other things, it means that Dilithium signature would require fragmentation, or fail to transfer. If 253-octets limitation applies - then no PQ signature can work (without fragmentation)... On 10/12/22, 13:41, "OPSAWG on behalf of Alan DeKok" wrote: On Oct 12, 2022, at 1:32 PM, Ben Schwartz wrote: > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This is a problem, since it is meant to hold a SvcParams object that is allowed to be much larger (up to ~65000 octets in principle). The length is less than 253 octets, as it is encapsulated inside of another attribute "wrapper". So the practical limit is probably 250 or less. RADIUS provides for encoding more than 253 octets in an attribute. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 However, this capability exists only for "top level" attributes, and cannot be used here. Further, RADIUS packets are generally limited to 4K octets total. So even if the limits on this attribute are removed, then there's still a practical limit of around 4000 octets. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg smime.p7s Description: S/MIME cryptographic signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 12, 2022, at 1:32 PM, Ben Schwartz wrote: > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This is a > problem, since it is meant to hold a SvcParams object that is allowed to be > much larger (up to ~65000 octets in principle). The length is less than 253 octets, as it is encapsulated inside of another attribute "wrapper". So the practical limit is probably 250 or less. RADIUS provides for encoding more than 253 octets in an attribute. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 However, this capability exists only for "top level" attributes, and cannot be used here. Further, RADIUS packets are generally limited to 4K octets total. So even if the limits on this attribute are removed, then there's still a practical limit of around 4000 octets. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This is a problem, since it is meant to hold a SvcParams object that is allowed to be much larger (up to ~65000 octets in principle). On Wed, Oct 12, 2022 at 12:44 PM Joe Clarke (jclarke) wrote: > Forgot to include radext and add… > > > > *From: *OPSAWG on behalf of Joe Clarke > (jclarke) > *Date: *Wednesday, October 12, 2022 at 12:43 > *To: *opsawg@ietf.org > *Subject: *[OPSAWG] WG LC: RADIUS Extensions for Encrypted DNS > > Hello, WG. While this work was recently adopted, there was a considerable > amount of discussion and work put in to address issues and stabilize the > spec. The authors feel it has reached a steady state and is ready for WG > LC. Based on my read of the discussion threads, it does appear the major > issues have been addressed. > > > > Therefore, this serves as the start of a two week WG LC for > https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/. > Please provide your comments and/or support for the current spec on-list > prior to October 27. > > > > Thanks. > > > > Joe > -- > Add mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/add > smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
