Re: [Add] DNR's SvcParams encoding

[Tommy Pauly <[e-mail]>]

I’m still unclear on why the DHCP server would have a simpler time dealing with the text format. Handling an opaque string or an opaque binary blob (the wire format) should be equally simple — just pass the value that is configured.

As a client implementor, I would have no intention of building a SVCB parameters text parser. The wire format is clearly the simpler and more efficient choice.

I am also very concerned by the suggestion that using the text format would be used to advertise parameters that are not yet assigned or described. There is already a private use range that exists, and we should not be pushing for experimentation that only works in DNR and not DDR or other SVCB uses.

Tommy

> On Oct 3, 2023, at 6:50 AM, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> Hi Med,
> 
> You wrote:
> 
> Interoperability is even simplified between DHCP clients/servers as future svcparams can be conveyed using DNR without the need to wait of a number to be assigned by IANA for it. 
> 
> This strikes me as an argument against using text format here: it encourages shortcuts that bypass the standards process and create divergence between DNR and SVCB.
> 
> It's true that using text format on the wire probably simplifies the implementation of DHCP servers for DNR.  However, it increases the complexity of the system overall, because it requires the client to add a SVCB text-format parser that would likely not exist there otherwise.  DHCP servers, in contrast, are frequently integrated with a DNS server (e.g., as part of a split-horizon arrangement), which should contain a SVCB text format parsing library already.
> 
> --Ben Schwartz
> 
> From: Add <[e-mail] <mailto:[e-mail]>> on behalf of [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, October 3, 2023 1:49 AM
> To: Erik Nygren <[e-mail] <mailto:[e-mail]>>; Dan Wing <[e-mail] <mailto:[e-mail]>>
> Cc: Tommy Pauly <tpauly=[e-mail] <mailto:tpauly=[e-mail]>>; Paul Wouters <[e-mail] <mailto:[e-mail]>>; Stephen Farrell <[e-mail] <mailto:[e-mail]>>; ADD Mailing list <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Add] DNR's SvcParams encoding
>  
> This Message Is From an External Sender 
> Hi Erik, 
>  
> Please see inline. 
>  
> Cheers,
> Med
>  
> De : Add <[e-mail] <mailto:[e-mail]>> De la part de Erik Nygren
> Envoyé : mardi 3 octobre 2023 03:05
> À : Dan Wing <[e-mail] <mailto:[e-mail]>>
> Cc : Tommy Pauly <tpauly=[e-mail] <mailto:tpauly=[e-mail]>>; Paul Wouters <[e-mail] <mailto:[e-mail]>>; Stephen Farrell <[e-mail] <mailto:[e-mail]>>; ADD Mailing list <[e-mail] <mailto:[e-mail]>>
> Objet : Re: [Add] DNR's SvcParams encoding
>  
> I'm not sure I follow why the presentation format is needed for this?  The SVCB specification already allows for this with the keyNNN syntax.
> Even if the DHCP server doesn't support a new service parameter key it can still be specified in presentation format in keyNNN=<encoded_value>.
>  
> [Med] Sure, and this is what the current DNR and IKE-DNR are doing. New service parameters can be conveyed easily mainly because we don’t require any conversion from the parameter label to an integer (as in the wire format). Interoperability is even simplified between DHCP clients/servers as future svcparams can be conveyed using DNR without the need to wait of a number to be assigned by IANA for it. We soften as much the dependency on underlying DHCP libraries, without complexifying required configuration tasks for DNR and IKE-DNR operators.
>  
> (In early design stages of SVCB we considered having something more unified such as using CBOR but then landed on the specified mechanism instead with the separate presentation format and wire format since that is more consistent with what the rest of DNS does.)
>  
>    Erik
>  
>  
> On Mon, Oct 2, 2023 at 8:00 PM Dan Wing <[e-mail] <mailto:[e-mail]>> wrote:
> The goal of spec'ing presentation format was to allow new Service Parameter Key to be defined and deployed without needing support in the DHCP server.  I agree a BASE64-encoded blob containing the service parameter would also get us there -- somewhat akin to how DHCP servers have long handled new DHCP option numbers until the DHCP server was upgraded to support the new option number.   But we would need a tool to create that BASE64 blob.  Maintaining the BASE64 blob would be a pain as it can't be read or verified directly, and (depending on the wire format) may also need a tool to convert from binary to human-readable text.  This operational effort will likely cause network operators to wait until their DHCP server has native support for a new Service Parameter.
>  
> -d
>  
>  
> 
> 
> On Oct 2, 2023, at 2:06 PM, Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
> 
> 
> On Oct 2, 2023, at 1:50 PM, Paul Wouters <[e-mail] <mailto:[e-mail]>> wrote:
>  
> On Oct 2, 2023, at 16:27, Stephen Farrell <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 
> Hiya,
> 
> I don't really have an axe to grind here but fwiw think Erik
> and earlier posts on the same line are correct about this.
> 
> I was thinking the reverse. I agree dhcp servers on small routers shouldn’t be forced to convert configuration file syntax which has to be in presentation mode, into wire format dns.
>  
> Why should we be asking them to convert? Can we just configured them with the binary version (as base64 or something)?
>  
> Tommy
> 
> 
> 
> Paul
> 
> 
> 
> Cheers,
> S.
> 
> 
> On 02/10/2023 20:29, Erik Nygren wrote:
> Lots of ambiguity issues start showing up if we include the presentation
> format, as well as interop issues which are primarily addressed through the
> wire format but not as clearly in the presentation format.  Some of these
> also open up potentials for security vulnerabilities.
> If we were to expect clients to interop by sending messages in presentation
> format there are likely sets of design and security considerations which
> we'd need to address which aren't addressed in the draft(s).
> As an example, that "key1=\1522" and "alpn=h2" are the same thing and both
> valid seems like a horrible thing to have to put into DHCP clients.
> I'd be strongly in-favor of clarifying/fixing this to use wire format even
> if it means delay in getting the cluster out.  (We should probably have the
> drafts be clear that this is "wire format" in their text as well, not just
> give a section reference.)
> <OpenPGP_0xE4D8E9F997A833DD.asc>
> --
> Add mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add
> 
> -- 
> Add mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add
>  
> -- 
> Add mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add
>  
> -- 
> 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.
> -- 
> Add mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add