Re: [Add] DNR's SvcParams encoding

[[e-mail]]

Hi all,

It is surprising to raise this objection now given that text was there since -01: https://datatracker.ietf.org/doc/draft-ietf-add-dnr/01/ (May 2021) and the intent was clarified during the AD review. The rationale was to supply a blob in DHCP, not inherit DNS wire format.

I even had a thread with Chris with that section explicitly mentioned: https://mailarchive.ietf.org/arch/msg/add/05eABH5YubZPoqj3wBMMdsdhTrg/.

FWIW, I know that at least https://reports.kea.isc.org/dev_guide/d7/dee/classisc_1_1dhcp_1_1DnrInstance.html#a7f272a5323080bcf23228dc66c4069d5 followed that encoding.

Cheers,
Med

De : Add <[e-mail]> De la part de Ben Schwartz
Envoyé : vendredi 29 septembre 2023 19:33
À : Chris Box <[e-mail]>; ADD Mailing list <[e-mail]>
Objet : Re: [Add] DNR's SvcParams encoding

I expected interpretation A, and would correct the reference to point to Section 2.2.  I would have serious concerns about publication under interpretation B.

--Ben Schwartz
________________________________
From: Add <[e-mail]<mailto:[e-mail]>> on behalf of Chris Box <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 29, 2023 1:27 PM
To: ADD Mailing list <[e-mail]<mailto:[e-mail]>>
Subject: [Add] DNR's SvcParams encoding

Hi everyone DNR is currently in the RFC queue, as part of a cluster in AUTH48 (https: //www. rfc-editor. org/cluster_info. php?cid=C461). As part of recent implementation work, it's become apparent to me that there are two possible interpretations
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Hi everyone

DNR is currently in the RFC queue, as part of a cluster in AUTH48 (https://www.rfc-editor.org/cluster_info.php?cid=C461).

As part of recent implementation work, it's become apparent to me that there are two possible interpretations of DNR's description of the wire encoding of SvcParams.

DNR draft 16 says this.

   Service Parameters (SvcParams) (variable length):  Specifies a set of
      service parameters that are encoded following the rules in
      Section 2.1 of [I-D.ietf-dnsop-svcb-https].  Service parameters
      may include, for example, a list of ALPN protocol identifiers or
      alternate port numbers.  This field SHOULD include at least "alpn"
      SvcParam.  The "alpn" SvcParam may not be required in contexts
      such as a variant of DNS over CoAP where messages are encrypted
      using OSCORE.  The service parameters MUST NOT include "ipv4hint"
      or "ipv6hint" SvcParams as they are superseded by the included IP
      addresses.

I'll describe the two different ways to understand that.

Human interpretation A

Section 2.1<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.1> is "Zone file presentation format". This interpretation considers that this section is simply a description of how such information would appear if it was in a zone file, and does not define a wire format. In the case of DNR, this implies that the wire format of the SvcParams field of the DHCP option ought to follow Section 2.2<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2> which is "RDATA wire format".

An example DNR option response could be:
Tag (0xA2)
Length
DNR Instance Data Length
Service Priority (0x0001)
ADN Length
ADN (0x04 "doh1" 0x07 "example" 0x03 "com" 0x00)
Addr Length
Address (0xC0 0x0 0x2 0x1)
SvcParams (0x0001 0x0002 "h2" 0x0007 0x0010 "/dns-query{?dns}")

This is a format where the last part is similar to what a DDR client would receive in the answer to its SVCB request. So in that sense, DNR is similar to DDR.


Human interpretation B

Section 2.1<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.1> is followed literally, and therefore the wire format of the SvcParams is in zone file format.
Tag (0xA2)
Length
DNR Instance Data Length
Service Priority (0x0001)
ADN Length
ADN (0x04 "doh1" 0x07 "example" 0x03 "com" 0x00)
Addr Length
Address (0xC0 0x0 0x2 0x1)
SvcParams ("alpn=h2 dohpath=/dns-query{?dns}")

This obviously requires textual parsing by the recipient, which is different to DDR.


My question to you all is: when you considered DNR during WGLC, which interpretation did you have? Rough concensus was declared, but I wonder whether we all had the same interpretation of the meaning of the text when we did so.

Looking back, I see Eric did pick up on this ambiguity in his AD review: https://mailarchive.ietf.org/arch/msg/add/SFIpMWvnhzTkMDWKQkrl_jGMC6E/ He expressed doubt about interpretation B, but did not block. Unfortunately I did not see this exchange at the time.

Which interpretation did you consider at the time?

Chris
____________________________________________________________________________________________________________
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.