Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

[Bernie Volz <[e-mail]>]

I’m really not sure why there is any confusion. I think changing Section 3.1 and 3.2 (obviously with some edits for 3.2) from:

      Permitted DHCPv6 options in the DHCPv6-Options Attribute are
      maintained by IANA in the registry created in Section 8.4.1.

to:

      Permitted DHCPv6 options in the DHCPv6-Options Attribute are
      maintained by IANA in the registry created in Section 8.4.1. If a
      DHCP server finds an option not permitted, it MUST ignore that
      option.

Would be a simple and reasonable fix. This doesn’t fully address the malformed data, such as extra data at end of attribute value that is less than 4 octets (dhcpv6 options have a 4-octet header) or when an option specifies a length that exceeds the remaining data in the attribute, but I’ll allow those issues to be handled by the RADIUS documents as an invalid attribute.

Note that I don’t believe RFC7037 documented what should happen if Radius Attributes that are not permitted are present in the data. But that doesn’t mean as time goes on we shouldn’t become wiser and improve our standards to cover more of the potential “bad” considerations.

Until Éric raised it, I hadn’t thought about it either. Éric might still want to cover these malformed data issues …

>> - not limit itself on the validity of the RADIUS attribute but
>> also clearly state what the DHCP server validation should do


Also, Section 5 is also a bit lacking in how the DHCP server handles this. Yes, I know what is expected as having worked with DHCP for a long time … but standing back a bit, really is not that clear. You might want to review Section 6 of RFC 6422. In your case, you likely want the server to prefer this option over whatever it may already have.

- Bernie Volz

> On Mar 16, 2023, at 10:59 AM, [e-mail] wrote:
> 
> Hi Éric, 
> 
> Thank you for the follow-up.
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Eric Vyncke (evyncke) <[e-mail]>
>> Envoyé : jeudi 16 mars 2023 14:43
>> À : Bernie Volz <[e-mail]>; BOUCADAIR Mohamed INNOV/NET
>> <[e-mail]>
>> Cc : The IESG <[e-mail]>; draft-ietf-opsawg-add-encrypted-
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Objet : Re: Éric Vyncke's Discuss on draft-ietf-opsawg-add-
>> encrypted-dns-11: (with DISCUSS and COMMENT)
>> 
>> Thank you all for this open discussion among RADIUS and DCHP
>> knowledgeable people.
>> 
>> From what I read in various email threads and imho (that could be
>> wrong of course),  this draft should still be revised to:
>> - handle the differences between DHCP attributes and options (per
>> Bernie's email below)
> 
> [Med] I still don't see what the issue is. I trust Bernie will further explain the issue. 
> 
>> - handle both IPv4 and IPv6
>> - not limit itself on the validity of the RADIUS attribute but
>> also clearly state what the DHCP server validation should do
> 
> [Med] If DHCP servers behave as RADIUS clients, the usual RFC6929 validation are followed. We have a NEW text with a reminder. This applies to both v4/v6 attributes.
> If DHCP relay agents behave as RADIUS clients, then the validation in RFC7037 (DHCPv6) and RFC4014+Updates in this draft (DHCPv4) are followed by DHCP servers. 
> 
> What additional validation is missing?
> 
>> - the "SHOULD ignore" of section 4.2.2  is dangling... Why not a
>> MUST or the reason why the SHOULD is not followed should be
>> described
>> 
> 
> [Med] That SHOULD was already in RFC4014. That’s said, and as you can see in https://tinyurl.com/opsawg-add-latest, we have now a NEW text to explain when the SHOULD is not followed. 
> 
>> Let's all work together to address those concerns, they seem easy
>> to fix.
>> 
>> Regards
>> 
>> -éric
>> 
>> On 14/03/2023, 14:06, "iesg on behalf of Bernie Volz" <iesg-
>> [e-mail] <mailto:[e-mail]> on behalf of
>> [e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> Section 4.2 is about DHCPv4 and updates to RFC4014. So maybe that
>> solves the issue for section 3.2 but not for 3.1? Also, while you
>> say section 3 is about Radius attributes, it talks about dhcp
>> options. And specifically says “ Permitted DHCPv6 options in the
>> DHCPv6-Options Attribute are maintained by IANA in the registry
>> created in Section 8.4.1.” So it begs the question about what
>> happens if unpermitted options present (this could be an
>> interoperability issue as perhaps the registry is extended and the
>> radius side is updated but the dhcp server isn’t and hence finds
>> options that aren’t allow by its table). Or someone stuffs a dhcp
>> option in there that isn’t allowed.
>> 
>> 
>> You also reference:
>> 
>> 
>>> If the relay agent relays RADIUS attributes not included in the
>>> IANA-maintained registry (Section 8.3 of [This-Document]), the
>> DHCP
>>> server SHOULD ignore them.
>> 
>> 
>> But this is about attributes again, not options. Your new DHCPv*-
>> Options Attributes can contain many DHCP options. So I think being
>> clear about what happens with the potential options inside this
>> single attribute is important to clarify.
>> 
>> 
>> - Bernie (from iPad)
>> 
>> 
>>> On Mar 14, 2023, at 7:49 AM, [e-mail]
>> <mailto:[e-mail]> wrote:
>>> 
>>> Hi Bernie,
>>> 
>>> Thank you for sharing your thoughts.
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Bernie Volz <[e-mail] <mailto:[e-mail]>>
>> Envoyé
>>>> : mardi 14 mars 2023 12:10 À : BOUCADAIR Mohamed INNOV/NET
>>>> <[e-mail]
>> <mailto:[e-mail]>>
>>>> Cc : Éric Vyncke <[e-mail]
>> <mailto:[e-mail]>>; The
>>>> IESG <[e-mail] <mailto:[e-mail]>>;
>>>> [e-mail]
>>>> <mailto:[e-mail]>; opsawg-
>>>> [e-mail] <mailto:[e-mail]>; [e-mail]
>>>> <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>;
>>>> [e-mail] <mailto:[e-mail]> Objet : Re: Éric
>>>> Vyncke's Discuss on draft-ietf-opsawg-add-
>>>> encrypted-dns-11: (with DISCUSS and COMMENT)
>>>> Med:
>>>> Eric asked about how non-permitted dhcp options are to be
>> handled in
>>>> section 3.1/3.2; you responded about RADIUS attributes?
>>> 
>>> [Med] Yes, because these sections are about RADIUS attributes
>> (and thus not about the behavior of DHCP servers). But I may be
>> missing something.
>>> 
>>>> Wouldn’t just saying that the DHCP server should ignore non-
>>>> permitted DHCP options but continue otherwise (process
>> remaining)?
>>>> (The server may also log about dropped options to alert
>>>> administrators to a potential misconfiguration.)
>>> 
>>> [Med] That’s is covered, e.g., in the Update in Section 4.2.2:
>>> 
>>> If the relay agent relays RADIUS attributes not included in the
>>> IANA-maintained registry (Section 8.3 of [This-Document]), the
>> DHCP
>>> server SHOULD ignore them.
>>> 
>>> For DHCPv6, that is supposed to be handled as per RFC7037. We
>> are not touching any part of that spec. No?
>>> 
>>>> Of course if the data is malformed, then following existing
>> policies
>>>> (rfc6929) is prudent. Though even there it isn’t 100% clear
>> what to
>>>> do if the attribute is well formatted but the option data is
>> bad -
>>>> mostly the length of the last DHCP option exceeds the remaining
>> data
>>>> in the RADIUS attribute. I doubt we expect RADIUS or DHCP
>> servers to
>>>> assure that each individual option is valid (such as the length
>> is a
>>>> multiple of 4 or 16 if data is list of addresses).
>>>> - Bernie (from iPad)
>>>>>> On Mar 14, 2023, at 6:38 AM, [e-mail]
>> <mailto:[e-mail]> wrote:
>>>>> Hi Éric,
>>>>> Thank you for the review. The changes to address your review
>> can
>>>> be seen at: https://tinyurl.com/opsawg-add-latest
>> <https://tinyurl.com/opsawg-add-latest>.
>>>>> Please see inline.
>>>>> Cheers,
>>>>> Med
>>>>>> -----Message d'origine-----
>>>>>> De : Éric Vyncke via Datatracker <[e-mail]
>> <mailto:[e-mail]>> Envoyé :
>>>> mardi 14
>>>>>> mars 2023 10:30 À : The IESG <[e-mail]
>> <mailto:[e-mail]>> Cc :
>>>>>> [e-mail]
>>>>>> <mailto:[e-mail]>;
>> opsawg-
>>>>>> [e-mail] <mailto:[e-mail]>; [e-mail]
>>>>>> <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>;
>>>> [e-mail] <mailto:[e-mail]>;
>>>>>> [e-mail] <mailto:[e-mail]>; [e-mail]
>>>>>> <mailto:[e-mail]> Objet : Éric Vyncke's
>>>> Discuss on
>>>>>> draft-ietf-opsawg-add-encrypted-
>>>>>> dns-11: (with DISCUSS and COMMENT)
>>>>>> Éric Vyncke has entered the following ballot position for
>>>>>> draft-ietf-opsawg-add-encrypted-dns-11: Discuss When
>> responding,
>>>>>> please keep the subject line intact and reply
>>>> to all
>>>>>> email addresses included in the To and CC lines. (Feel free
>> to
>>>> cut
>>>>>> this introductory paragraph, however.) Please refer to
>>>>>> https://www.ietf.org/about/groups/iesg/statements/handling-
>>>>>> <https://www.ietf.org/about/groups/iesg/statements/handling->
>>>> ballot-
>>>>>> positions/
>>>>>> for more information about how to handle DISCUSS and COMMENT
>>>>>> positions.
>>>>>> The document, along with other ballot positions, can be found
>>>>>> here:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-
>>>>>> <https://datatracker.ietf.org/doc/draft-ietf-opsawg-add->
>>>> encrypted-
>>>>>> dns/
>>>>>> -------------------------------------------------------------
>> --
>>>> ---
>>>>>> ----
>>>>>> DISCUSS:
>>>>>> -------------------------------------------------------------
>> --
>>>> ---
>>>>>> ----
>>>>>> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-add-
>>>>>> encrypted-dns-11
>>>>>> CC @evyncke
>>>>>> Thank you for the work put into this document. Once the
>> trivial
>>>>>> DISCUSS is addressed, I will be happy to ballot a YES.
>>>>>> Please find below one blocking DISCUSS points (easy to
>>>> address), some
>>>>>> non-blocking COMMENT points (but replies would be appreciated
>>>> even if
>>>>>> only for my own education), and some nits.
>>>>>> Special thanks to Bernie Volz for the shepherd's detailed
>>>> write-up
>>>>>> including the WG consensus even if the justification of the
>>>> intended
>>>>>> status is rather vague.
>>>>>> Other thanks to Tatuya Jinmei, the Internet directorate
>>>> reviewer (at
>>>>>> my request), please consider this int-dir review:
>>>>>> https://datatracker.ietf.org/doc/review-ietf-opsawg-add-
>>>>>> <https://datatracker.ietf.org/doc/review-ietf-opsawg-add->
>>>> encrypted-
>>>>>> dns-10-intdir-telechat-jinmei-2023-03-09/
>>>>>> (and I have read Med's replies and resolution of the issues)
>> I hope
>>>>>> that this review helps to improve the document, Regards, -
>> éric ##
>>>>>> DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-
>> ballot-
>>>>>> <https://www.ietf.org/blog/handling-iesg-ballot->
>>>>>> positions/, a
>>>>>> DISCUSS ballot is a request to have a discussion on the
>>>> following
>>>>>> topics:
>>>>>> ### What to do with non-permitted DHCP option ?
>>>>>> Sections 3.1 and 3.2 contain text like `Permitted DHCPv6
>>>> options in
>>>>>> the DHCPv6-Options Attribute are maintained by IANA in the
>>>> registry
>>>>>> created in Section 8.4.1.` but I was unable to find anywhere
>> in
>>>> the
>>>>>> document what is the expected behaviour of a RADIUS client
>>>> receiving
>>>>>> a non-permitted DHCP option ?
>>>>>> At the bare minimum, I would expect the I-D to mention "non-
>>>>>> permitted DHCP options MUST silently be ignored by the RADIUS
>>>> client"
>>>>> [Med] Absent any local policy, non-permitted attributes should
>>>> be considered as invalid (rfc6929#section-2.8).
>>>>> RADIUS attributes specs usually don't repeat validation checks
>>>> as this is redundant with rfc8044, especially:
>>>>> Where the contents of a data type do not match the definition,
>>>>> implementations MUST treat the enclosing attribute as being an
>>>>> invalid attribute. This requirement includes, but is not
>>>> limited to,
>>>>> the following situations...
>>>>> Unless Alan has a string objection, we can add this generic
>> text
>>>> right before Section 3.1:
>>>>> "As a reminder, invalid attributes are handled as per Section
>>>> 2.8 of [RFC6929]".
>>>>>> Or did I fail to find a similar statement in the text ?
>>>>>> -------------------------------------------------------------
>> --
>>>> ---
>>>>>> ----
>>>>>> COMMENT:
>>>>>> -------------------------------------------------------------
>> --
>>>> ---
>>>>>> ----
>>>>>> ## COMMENTS
>>>>>> ### Abstract
>>>>>> Should the sentence `Even if the specification was initially
>>>>>> motivated by the configuration of encrypted DNS resolvers,`
>> be
>>>>>> removed from the abstract ? It adds nothing but confusion.
>>>>> [Med] OK, deleted that part of the sentence.
>>>>>> ### Section 3
>>>>>> Should the whole paragraph starting with `RADIUS servers have
>>>>>> conventionally tolerated the input of arbitrary data via the
>>>> "string"
>>>>>> data type (Section 3.5 of [RFC8044])... ` rather be in the
>>>> security
>>>>>> (or operational) considerations section ?
>>>>> [Med] Good suggestion. Fixed.
>>>>>> ### Section 3.1
>>>>>> Should normative language be used in `However, the server is
>>>> not
>>>>>> required to honor such a preference.`? I.e., the rest of the
>>>>>> paragraph uses normative language.
>>>>> [Med] I'm afraid that "s/is no/MAY NOT" is not justified here
>> as
>>>> the client is prepared that its preference to be ignored. There
>> is no
>>>> impact on interop or there will be a "reduced functionality".
>>>>>> ### Section 4
>>>>>> Should 'DHCP relay' be mentioned in the section title ? It
>>>> would of
>>>>>> course be very long then but clearer for the reader (esp in
>> the
>>>> ToC)
>>>>> [Med] Works for me.
>>>>>> ## NITS
>>>>>> ### Section 3.2
>>>>>> Suggest to use the same layout as in section 3.1 for the
>>>> "value"
>>>>>> field.
>>>>> [Med] Thanks for catching this. Fixed
>>>> 
>> __________________________________________________________________
>>>> ____
>>>>> ___________________________________________________
>>>>> 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.
>>> 
>>> 
>> __________________________________________________________________
>> ____
>>> ___________________________________________________
>>> 
>>> 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.
>> 
>> 
>> 
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>