Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
On Tue, Mar 14, 2023 at 11:47 PM wrote: > To further insist this is about an example, I made the following change: > > OLD: > 5. Applicability to Encrypted DNS Provisioning > > NEW: > 5: An Example: Applicability to Encrypted DNS Provisioning > > This change together with the current text is much more clear this is an > example to illustrate the use of This works for me. I'd leave it to you whether to make the following change. > == >Typical deployment scenarios are similar to those described, for >^^ >instance, in Section 2 of [RFC6911]. For illustration purposes, > ^^ >Figure 1 shows an example where a Customer Premises Equipment (CPE) >is provided with an encrypted DNS resolver. This example assumes > >that the Network Access Server (NAS) embeds both RADIUS client and >DHCPv6 server capabilities. > == And, as I noted in my previous message, I suggest removing the reference to RFC6977. Specifically, remove this sentence from the last paragraph of Section 6: Additional considerations specific to the use of Reconfigure messages are discussed in Section 9 of [RFC6977]. and [RFC6977] from Section 10.2. -- jinmei ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
Hi Tatuya, Thank you for the follow-up. Much appreciated. > If you're saying that this is just an example and its > applicability doesn't matter much, then I'd be happier if it were > clearer that the content of this section is a mere example. The introduction says the following: A sample deployment usage of the DHCPv6-Options and DHCPv4-Options RADIUS attributes is described in Section 5. To further insist this is about an example, I made the following change: OLD: 5. Applicability to Encrypted DNS Provisioning NEW: 5: An Example: Applicability to Encrypted DNS Provisioning This change together with the current text is much more clear this is an example to illustrate the use of == Typical deployment scenarios are similar to those described, for ^^ instance, in Section 2 of [RFC6911]. For illustration purposes, ^^ Figure 1 shows an example where a Customer Premises Equipment (CPE) is provided with an encrypted DNS resolver. This example assumes that the Network Access Server (NAS) embeds both RADIUS client and DHCPv6 server capabilities. == Hope this is better. Cheers, Med > -Message d'origine- > De : JINMEI Tatuya / 神明達哉 > Envoyé : mercredi 15 mars 2023 00:54 > À : BOUCADAIR Mohamed INNOV/NET > Cc : int-...@ietf.org; draft-ietf-opsawg-add-encrypted- > dns@ietf.org; last-c...@ietf.org; opsawg@ietf.org > Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg- > add-encrypted-dns-10 > > >> I'm fine with deferring such a discussion to draft-ietf-add- > dnr; I'm > >> also fine with just removing any reference to Reconfigure from > this > >> draft (and maybe stating that's an out- of-scope topic). > > > [Med] I don't understand this position as what we are discussing > here > > is ** an example ** (not a reco or a new feature) to illustrate > the > > use of the attributes with CoA. That example wouldn’t be > complete if > > the DHCP leg is not exemplified as well. Issues with reconfigure > are > > well-known and adequate references for readers who want to learn > more > > are now provided in the document. > > One main concern of mine is that it's not so clear whether it's > just an example or not. I actually also thought this section is > intended just as an example. But it's one of the body of this > document (not in an appendix), and while the RADIUS part of the > protocol is generic, it's obvious the primary motivation is to use > it for ietf-add-dnr. So I also thought the applicability of this > section may have to be discussed in more detail, either in this > doc or in ietf-add-dnr. > > If you're saying that this is just an example and its > applicability doesn't matter much, then I'd be happier if it were > clearer that the content of this section is a mere example. One > clear way for that is to move this section to an appendix. > Another would be to add a sentence or two clarifying that intent > at the top of that section. > > If you're not willing to do either, I think we should agree to > disagree here. In that case please feel free to dismiss my point. > I'd also suggest removing the reference to RFC6977, since it was > added to address my comment but it doesn't address it anyway. > > -- > jinmei _ 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] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
>> I'm fine with deferring such a discussion to >> draft-ietf-add-dnr; I'm also fine with just removing any reference >> to Reconfigure from this draft (and maybe stating that's an out- >> of-scope topic). > [Med] I don't understand this position as what we are discussing > here is ** an example ** (not a reco or a new feature) to illustrate > the use of the attributes with CoA. That example wouldn’t be > complete if the DHCP leg is not exemplified as well. Issues with > reconfigure are well-known and adequate references for readers who > want to learn more are now provided in the document. One main concern of mine is that it's not so clear whether it's just an example or not. I actually also thought this section is intended just as an example. But it's one of the body of this document (not in an appendix), and while the RADIUS part of the protocol is generic, it's obvious the primary motivation is to use it for ietf-add-dnr. So I also thought the applicability of this section may have to be discussed in more detail, either in this doc or in ietf-add-dnr. If you're saying that this is just an example and its applicability doesn't matter much, then I'd be happier if it were clearer that the content of this section is a mere example. One clear way for that is to move this section to an appendix. Another would be to add a sentence or two clarifying that intent at the top of that section. If you're not willing to do either, I think we should agree to disagree here. In that case please feel free to dismiss my point. I'd also suggest removing the reference to RFC6977, since it was added to address my comment but it doesn't address it anyway. -- jinmei ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
Hi Tatuya, Thank you for the feedback. Please see inline. Cheers, Med > -Message d'origine- > De : JINMEI Tatuya / 神明達哉 > Envoyé : lundi 13 mars 2023 20:46 > À : BOUCADAIR Mohamed INNOV/NET > Cc : int-...@ietf.org; draft-ietf-opsawg-add-encrypted- > dns@ietf.org; last-c...@ietf.org; opsawg@ietf.org > Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg- > add-encrypted-dns-10 > > > [Med] OK. Added a reminder of where to find dhcp-related > security > > issues with a specific RFC for reconfigured-specific issues > (RFC6977). > > RFC6977 is specific to reconfiguration with relay agents., and > just provides generic discussions. [Med] The base specs + 6977 provides good pointers for security considerations that are relevant to DHCP-triggered reconfiguration upon receipt of CoA. Both considerations at the servers/relays are covered in these specs. If you have better informative pointers, please share them. Thanks. What I expected in this draft > in this context is how such discussions can apply to this specific > usage of Section 5. [Med] Section 5 illustrates how CoA-requests can be used to carry the new attributes and how a change of the configuration is propagated till the requesting client. Security considerations on the server/relay--dhcp clients are those that are discussed in the generic documents + specific dhcp options. Hence, the current wording in the Sec Sections. I'm fine with deferring such a discussion to > draft-ietf-add-dnr; I'm also fine with just removing any reference > to Reconfigure from this draft (and maybe stating that's an out- > of-scope topic). [Med] I don't understand this position as what we are discussing here is ** an example ** (not a reco or a new feature) to illustrate the use of the attributes with CoA. That example wouldn’t be complete if the DHCP leg is not exemplified as well. Issues with reconfigure are well-known and adequate references for readers who want to learn more are now provided in the document. But the added reference to RFC6977 doesn't > address my point. > > > [Med] Thanks. We went with a more elaborated version to better > explain > > the intent and call out the constraints: > > Thank you for the update. It looks good to me. > [Med] Great. > -- > jinmei _ 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] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
> [Med] OK. Added a reminder of where to find dhcp-related security > issues with a specific RFC for reconfigured-specific issues > (RFC6977). RFC6977 is specific to reconfiguration with relay agents., and just provides generic discussions. What I expected in this draft in this context is how such discussions can apply to this specific usage of Section 5. I'm fine with deferring such a discussion to draft-ietf-add-dnr; I'm also fine with just removing any reference to Reconfigure from this draft (and maybe stating that's an out-of-scope topic). But the added reference to RFC6977 doesn't address my point. > [Med] Thanks. We went with a more elaborated version to better > explain the intent and call out the constraints: Thank you for the update. It looks good to me. -- jinmei ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
Hi Tatuya, Thank you for the follow-up. We submitted a new version to address your review: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-11. Please see inline for more context, fwiw. Cheers, Med > -Message d'origine- > De : JINMEI Tatuya / 神明達哉 > Envoyé : samedi 11 mars 2023 06:51 > À : BOUCADAIR Mohamed INNOV/NET > Cc : int-...@ietf.org; draft-ietf-opsawg-add-encrypted- > dns@ietf.org; last-c...@ietf.org; opsawg@ietf.org > Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg- > add-encrypted-dns-10 > > On Thu, Mar 9, 2023 at 10:23 PM > wrote: > > > [Med] What is actually more important in this para is the part > in > > [...]. That text is there to provide an example of when the > attributes > > can be present in CoA-Request. > > I have no problem with that part, and I didn't mean it's less > important than the use of DHCPv6 Reconfigure by omitting that > part. > > > [Med] These considerations are specific to the dhcp options that > will > > be carried in the RADIUS attribute. The security considerations > > (including issues with the use of reconfigure) fall under this > part: > > >> Security considerations specific to the DHCP options that are > >> carried in RADIUS are discussed in relevant documents that > specify > >> these options. > > Do you specifically mean draft-ietf-add-dnr-13? I first expected > that while reviewing draft-ietf-opsawg-add-encrypted-dns and > checked it, but it didn't discuss anything about DHCPv6 > Reconfigure. That's one reason why I raised the point in my > review. > > From your response, I'd suggest: > - Describe the DHCP part of reconfigure operation in more detail > in > draft-ietf-add-dnr (including whether to use Reconfigure message > in > the first place), and/or > - Remove the reference to DHCPv6 reconfigure from > opsawg-add-encrypted-dns and just say something like "How the > DHCPv6 > server uses the new encrypted DNS resolver information is out of > scope of this document." > [Med] OK. Added a reminder of where to find dhcp-related security issues with a specific RFC for reconfigured-specific issues (RFC6977). > > [Med] I also hesitated, but MAY is not used here as this does > not > > impact interop. I had to reread Sections 5/6 of RFC2119 > regularly for > > may/MAY. > > I don't object here. > > > [Med] The use of normative language is justified here because we > don't > > want the RADIUS servers to blindly pass data. What this text > says is > > that the attributes should not be seen as opaque data by the > RADIUS > > server but it should understand the encoding of the enclosed > options. > > Hmm, I didn't read it that way. If that's the intent (and if I > understand it correctly), "For ease of administrator > configuration" > especially sounds awkward, since it seems to say the purpose of > this requirement is better UX. Again, assuming I understand the > intent correctly, I'd suggest something like this: > > The RADIUS server SHOULD reject a configuration attempt of > including > a DHCP option in a DHCP*-Options RADIUS attribute if the server > does > not understand that DHCP option and its format. > [Med] Thanks. We went with a more elaborated version to better explain the intent and call out the constraints: NEW: RADIUS servers have conventionally tolerated the input of arbitrary data via the "string" data type (Section 3.5 of [RFC8044]). This practice allows RADIUS servers to support newer standards without software upgrades, by allowing administrators to manually create complex attribute content and, then, to pass that content to a RADIUS server as opaque strings. While this practice is useful, it is RECOMMENDED that RADIUS servers that implement the present specification are updated to understand the format and encoding of DHCP options. Administrators can, thus, enter the DHCP options as options instead of manually-encoded opaque strings. This recommendation increases security and interoperability by ensuring that the options are encoded correctly. It also increases usability for administrators. > -- > jinmei _ 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 susceptibl
Re: [OPSAWG] [dhcwg] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
On Thu, Mar 9, 2023 at 10:23 PM wrote: > [Med] What is actually more important in this para is the part in > [...]. That text is there to provide an example of when the > attributes can be present in CoA-Request. I have no problem with that part, and I didn't mean it's less important than the use of DHCPv6 Reconfigure by omitting that part. > [Med] These considerations are specific to the dhcp options that > will be carried in the RADIUS attribute. The security considerations > (including issues with the use of reconfigure) fall under this part: >> Security considerations specific to the DHCP options that are carried >> in RADIUS are discussed in relevant documents that specify these >> options. Do you specifically mean draft-ietf-add-dnr-13? I first expected that while reviewing draft-ietf-opsawg-add-encrypted-dns and checked it, but it didn't discuss anything about DHCPv6 Reconfigure. That's one reason why I raised the point in my review. >From your response, I'd suggest: - Describe the DHCP part of reconfigure operation in more detail in draft-ietf-add-dnr (including whether to use Reconfigure message in the first place), and/or - Remove the reference to DHCPv6 reconfigure from opsawg-add-encrypted-dns and just say something like "How the DHCPv6 server uses the new encrypted DNS resolver information is out of scope of this document." > [Med] I also hesitated, but MAY is not used here as this does not > impact interop. I had to reread Sections 5/6 of RFC2119 regularly > for may/MAY. I don't object here. > [Med] The use of normative language is justified here because we > don't want the RADIUS servers to blindly pass data. What this text > says is that the attributes should not be seen as opaque data by the > RADIUS server but it should understand the encoding of the enclosed > options. Hmm, I didn't read it that way. If that's the intent (and if I understand it correctly), "For ease of administrator configuration" especially sounds awkward, since it seems to say the purpose of this requirement is better UX. Again, assuming I understand the intent correctly, I'd suggest something like this: The RADIUS server SHOULD reject a configuration attempt of including a DHCP option in a DHCP*-Options RADIUS attribute if the server does not understand that DHCP option and its format. -- jinmei ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
