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&url2=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 <[email protected]> > Envoyé : jeudi 13 octobre 2022 17:16 > ΓΒ : Ben Schwartz <[email protected]> > CcΒ : Joe Abley <[email protected]>; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; Ben Schwartz > <[email protected]>; Joe Clarke (jclarke) > <[email protected]>; opsawg <[email protected]>; [email protected]; > ADD Mailing list <[email protected]> > ObjetΒ : Re: [Add] [OPSAWG] π WG LC: RADIUS Extensions for > Encrypted DNS > > On Oct 13, 2022, at 10:50 AM, Ben Schwartz <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
