Re: [Add] DNR's SvcParams encoding

[[e-mail]]

Hi Tommy,

I have no problem to make a change if there is a bug, but it isn’t for this specific case.

The rationale why we had 2.1 is to avoid requiring updating DHCP servers (or routers for RA) when new service parameters are defined. With the current approach, there is no need for server implementation to map a configured service parameter to an assigned IANA integer value in order to send it on the wire. The server just supplies the blob to clients (modulo validation in 2.1) which pass it to a DNS library.
I also have a concern that we will be breaking existing implems such as the one I already cited.

Cheers,
Med

De : Add <[e-mail]> De la part de Tommy Jensen
Envoyé : vendredi 29 septembre 2023 20:58
À : Tommy Pauly <tpauly=[e-mail]>; Ben Schwartz <bemasc=[e-mail]>; ADD Mailing list <[e-mail]>
Cc : Chris Box <[e-mail]>
Objet : Re: [Add] [EXTERNAL] Re: DNR's SvcParams encoding

Merging forks.

Med, I did the archaeology and also saw this was here since -01. I’m going to admit my part in this as a supporter of the wire format, both as a co-author and as a client implementor. I did not read carefully enough and assumed the reference to SVCB enabled the wire format, not the presentation format, given the reuse of parsers between DNR and DDR, along with the concerns Ben is likely referring to with presentation format on the wire.

Anyway, the point isn’t that this is a new objection, just a failure on us collectively in determining that we ended up addressing what we thought was there. I’m as big a fan of DNR as the next person, though I now wish we had gotten to our prototype sooner.

I don’t know what the process is for making this change, but even if it means pulling it back to the WG, I think we need to fix this before we are all stuck with 1) using text format on the wire, 2) all violating RFC, 3) doing an immediate -bis. I say that with all the pain of a co-author of two docs in this AUTH48 cluster, which I know others share. Silver lining: at least we do have time to discuss this, even if at the 11.99th hour.

Thanks,
Tommy


From: Add [e-mail]<mailto:[e-mail]> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, September 29, 2023 10:53 AM
To: Ben Schwartz bemasc=[e-mail]<mailto:bemasc=[e-mail]>; Chris Box [e-mail]<mailto:[e-mail]>; ADD Mailing list [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [Add] DNR's SvcParams encoding

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
From: Add <[e-mail]<mailto:[e-mail]>> On Behalf Of Tommy Pauly
Sent: Friday, September 29, 2023 11:23 AM
To: Ben Schwartz <bemasc=[e-mail]<mailto:bemasc=[e-mail]>>; ADD Mailing list <[e-mail]<mailto:[e-mail]>>
Cc: Chris Box <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [Add] DNR's SvcParams encoding

I would also expect interpretation A. Agreed with Ben about concerns for B.

I expect that this wasn’t caught since it is easy to not follow the Section 2.1 reference and assume it is applying to the wire format.

Thanks,
Tommy

On Sep 29, 2023, at 10:33 AM, Ben Schwartz <bemasc=[e-mail]<mailto:bemasc=[e-mail]>> wrote:

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

This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
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
--
Add mailing list
[e-mail]<mailto:[e-mail]>
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.