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 <add-bounces@ietf.org> De la part de Alan DeKok
> Envoyé : mercredi 12 octobre 2022 20:11
> À : Ben Schwartz <bemasc@google.com>
> Cc : Joe Clarke (jclarke) <jclarke@cisco.com>; opsawg@ietf.org;
> radext@ietf.org; add@ietf.org
> Objet : Re: [Add] [OPSAWG] 🔔 WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> On Oct 12, 2022, at 1:53 PM, Ben Schwartz <bemasc@google.com>
> 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
> Add@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.