Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Alan DeKok <[email protected]> > Envoyé : mercredi 5 octobre 2022 15:38 > À : Bernie Volz <[email protected]> > Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected]; [email protected] > Objet : Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS > Option: Encrypted DNS > > On Oct 5, 2022, at 8:37 AM, Bernie Volz <[email protected]> wrote: > > One minor item you may want to look at is whether “text” is the > best way to label the following data type in Table 2: > > > > TBA3 | Encrypted-DNS-ADN | text | This-Document, > | > > | | | | > > Section 3.3.1 > > > > Perhaps “dns wire encoding” might be better? > > If it's encoded as a sequence of DNS labels (length + data, > length + data, 00), then the correct RADIUS data type is "string" > [RFC8044] Section 3.5: > [Med] Good point. This would be consistent with this part in the draft: This field includes a fully qualified domain name of the encrypted DNS resolver. This field is formatted as specified in Section 10 of [RFC8415]. > The "string" data type encodes binary data as a sequence of > undistinguished octets. ... > > > Someone that just uses this table may get it wrong? While > perhaps there is some definition of “text” for Radius attributes, > a quick check of some seems to show that it is mostly used for > textual values. > > RFC 8044 Section 3.4 says this: > > The "text" data type encodes UTF-8 text ... > > > But perhaps you have limited choices here and other dns encoded > attributes already use text? > > There are other attributes in RADIUS which encode host names, > but those are all printable / UTF-8. > > I think this is the first RFC which uses the "dns encoding" > format for DNS names. [Med] FWIW, https://www.iana.org/assignments/radius-types/radius-types.xhtml lists the following: 144 DS-Lite-Tunnel-Name text [RFC6519] but RFC6519 itself says the following: The data type of the DS-Lite-Tunnel-Name RADIUS attribute is a string with opaque encapsulation, according to Section 5 of [RFC2865]. RFC 8044 allows the transport of non-RADIUS > data types when that data is simply carried in RADIUS, and is not > supposed to be interpreted or used by a RADIUS client or server. > > In this case, I think it's a wash. Everything else in RADIUS > uses printable strings. But if this attribute is simply sent to a > another system which copies it into a DHCPv6 packet as-is, then > that's fine. > > i.e. "this attribute is then copied verbatim into a DHCPv6 > attribute ????" > > Such text is missing from the document. The Introduction does > imply that the RADIUS attributes can be copied to DHCPv5: > > However, there are no > RADIUS attributes that can be used to populate the discovery > messages > discussed in [I-D.ietf-add-dnr]. > > But there is nothing which says "RADIUS attribute FOO is copied > to DHCPv6 option BAR". There should probably either be an > explicit mapping table given, or each attribute definition should > be extended with "this attribute is copied to DHCPv6 attribute > BAR" > > Without such direction, an implementor has to guess as to the > mapping. As an implementor, I would strongly prefer that the > document gives explicit direction. > > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
