[Add] Re: Introducing draft-liu-add-ppp-edns-negotiation-00

[Dan Wing <[e-mail]>]

Great.  Thanks.

-d


> On Oct 23, 2025, at 9:17 AM, dongjieliu8917 <[e-mail]> wrote:
> 
> Dear Dan Wing,
>  Thank you for your thoughtful question and valuable feedback. It has provided an excellent opportunity for us to clarify the design rationale and address potential concerns. Please find our detailed response below.
>  First, please allow us to clarify a key point: the "Server Selector" field we propose is an enumerated value, not a bitmask. The specific definitions are as follows:
> - `0x00`: This parameter block applies to the primary encrypted DNS server (Option 133).
> - `0x01`: This parameter block applies to the secondary encrypted DNS server (Option 134).
> - Other values are reserved for future use.
>  This means that multiple Option 135 instances can coexist during negotiation. Each is explicitly and exclusively bound to a specific DNS server via its `Server Selector` field. For example, one Option 135 (Selector=0x00) could specify an ALPN list for `dot-primary.example.com`, while another Option 135 (Selector=0x01) could specify a completely different DoH path for `doh-secondary.example.net`. This design fundamentally avoids the ambiguous scenario where "one parameter block needs to apply to both servers, but the two servers require different parameters."
>  We did consider using a bitmask scheme (e.g., bit 0 for primary, bit 1 for secondary). We acknowledge that, in theory, it allows a single parameter option to apply to multiple servers simultaneously, potentially slightly reducing message overhead in certain scenarios with shared parameters.
>  However, as you rightly pointed out, the core challenge with the bitmask scheme lies in resolving parameter conflicts when multiple parameter options exist and their target servers overlap. For example:
> - `Parameter Option #1`: `Server Mask = 0x01` (Primary only), `ALPN = "dot"`
> - `Parameter Option #2`: `Server Mask = 0x03` (Primary & Secondary), `ALPN = "h2"`
>  In such a case, the client would need a complex set of rules to determine the final ALPN value used for the primary and secondary servers. Possible rules (like "last one wins" or "most specific wins") would increase the complexity of state management. The client might need to maintain a version or priority state for each parameter type and each server. All these rules would significantly increase implementation complexity and the burden of interoperability testing.
>  Your question, however, reminded us that when multiple Option 135 instances exist, a client might receive multiple values for the same parameter type (e.g., ALPN list) targeting the same server. For instance:
> - Option 135: Server Selector = 0x00 (Primary), Param Type = 0x01 (ALPN), Value = "dot"
> - Option 135: Server Selector = 0x00 (Primary), Param Type = 0x01 (ALPN), Value = "h2"
>  To handle this conflict, we will explicitly add the "last one wins" principle in the draft: For the same server (specified by the Server Selector), if multiple options with the same Param Type are received, the client MUST use the parameter value from the last received Option 135 in the IPCP negotiation. This follows the standard negotiation behavior of RFC 1332 IPCP, ensuring determinism. Parameter options are processed independently per server. Parameter conflicts for the primary server only affect the primary server and do not impact the secondary server, and vice versa. If a client receives an unrecognized Param Type or an invalid value, it SHOULD ignore that specific option and continue processing other valid options, falling back to default behavior if necessary.
>  Regarding the Limitation on the Number of Servers
>  The current draft only defines options for primary (133) and secondary (134) servers, primarily based on the following considerations:
> - Adherence to Existing Conventions: Maintains structural and logical consistency with the widely deployed RFC 1877, facilitating understanding and adoption.
> - Sufficiency for Typical Scenarios: In the vast majority of PPP deployments (e.g., broadband access), a primary-backup architecture is sufficient to provide redundancy and reliability.
> - Controlled Protocol Complexity: Avoids making negotiation and state management overly complex.
>  Importantly, this does not preclude future extension. The protocol itself is extensible. If a clear future need arises (e.g., specifying a third server), it can be fully addressed by defining a new IPCP option type (e.g., Option 136). This provides a clear and backward-compatible path for protocol evolution.
>  Thank you again for your valuable input. We look forward to further discussions and collaboration.
>  Best regards,
> Dongjie Liu (on behalf of the authors)
> Jinan University
>  
> ---- Replied Message ----
> From Dan Wing<[e-mail]>
> Date 10/22/2025 04:33
> To dongjieliu8917<[e-mail]>
> Cc [e-mail]<[e-mail]>,
> [e-mail]<[e-mail]>,
> [e-mail]<[e-mail]>,
> [e-mail]<[e-mail]>
> Subject Re: [Add] Introducing draft-liu-add-ppp-edns-negotiation-00
> On Oct 21, 2025, at 1:54 AM, dongjieliu8917 <[e-mail]> wrote: 
> > 
> > Dear Dan Wing, 
> >  Thank you for your valuable comments and careful review of our draft. Your insights are highly appreciated. Please find our responses and proposed revisions below. 
> >  1. Regarding the applicability of the DNS Encryption Parameters Option (Section 2.3) 
> >  You raised a valid point that the current draft does not explicitly specify whether Option 135 applies to the Primary server (Option 133), the Secondary server (Option 134), or both. 
> >  Our Response & Proposed Change: 
> >  We agree that a mechanism is needed to specify different parameters for each server. To address this, we propose modifying the format of the DNS Encryption Parameters Option (Type 135) by adding a "Server Selector" field. 
> >  The updated format would be:Where: 
> > *   Server Selector (1 octet): 
> >    *   `0x00`: Parameters apply to the Primary Encrypted DNS Server (Option 133). 
> >    *   `0x01`: Parameters apply to the Secondary Encrypted DNS Server (Option 134). 
> >    *   Other values are reserved for future use. 
> >  In fact we considered several approaches to solve this, including nested options or separate option types per server. We selected the "Server Selector" field as it better balances several critical factors: 
> > 1. Clarity with Minimal Overhead: It solves the core disambiguation problem with an addition of only one byte to the option structure. 
> > 2. Backward Compatibility: Implementations that do not recognize this new field (e.g., because they are based on an earlier version of the draft) can safely ignore it or default to applying the parameters to the Primary server, ensuring no breakage in basic functionality. 
> > 3. Flexibility: It supports scenarios where a parameter (like a common ALPN list) applies to both servers, avoiding the need for duplicate options and reducing configuration overhead. 
> 
> (the diagram didn't make it through email.) 
> 
> It seems to be a bit mask:  if bit 0 is set, the parameters apply to the Primary server, if bit 1 is set, the parameters apply to the Secondary server.  If both bits are set, the parameters apply to both servers. 
> 
> Multiple parameter options could be present -- which makes sense if the Primary and Secondary server need different parameters. 
> 
> However, it's also confusing how the client should handle collisions and disagreements of the parameters.  As an example, there might be two parameter options:  the first one is just for the Primary server and contains a certain set of ALPN parameters, whereas the second parameter option has both bits set (so applies to both Primary and Secondary servers) and provides a different ALPN list.  The client needs guidance what to do in all such situations where there is a conflict.  The same problem can occur with DoH Path Template, and may well occur with new Internet Drafts that define new things in the Reserved space. 
> 
> 
> Is there a reason the protocol constrains to only define two DNS servers and prohibits three or more? 
> 
> 
> > 4. Protocol Evolution: This change represents a minimal, non-breaking extension to the option's semantics, adhering to the principle of minimal disruptive change. 
> >  2. Clarification on Client Request Behavior for Option 135 (Section 3.1) 
> >  You noted that the text "The client MAY include Option 135 to request specific parameters" needs elaboration on how the server should respond. 
> >  Our Response & Proposed Text Addition: 
> >  We propose adding the following text to Section 3.2 ("Server Response Behavior") to clarify the negotiation process for Option 135: 
> >  If the client includes a DNS Encryption Parameters Option (Option 135) in a Configure-Request, the server responds in one of the following ways: 
> > > - If the server supports **all** of the requested parameters, it MUST include them unchanged in a Configure-Ack. 
> > > - If the server supports a **subset** of the requested parameters, or supports alternative values for them, it SHOULD respond with a Configure-Nak containing a valid DNS Encryption Parameters Option with the parameters (and values) it is willing to support. 
> > > - If the server does not support encrypted DNS negotiation at all, or does not recognize Option 135, it SHOULD respond with a Configure-Reject for this option. 
> >  This aligns with standard IPCP negotiation behavior, promoting interoperability. 
> >  3. Concerns regarding Certificate Pinning (Section 2.3 & Appendix A.3) 
> >  You rightly pointed out the operational complexities associated with certificate pinning, such as handling valid certificate rotations. 
> >  Our Response & Proposed Change: 
> >  We agree with the concerns. Relying on certificate pinning can indeed lead to operational fragility. 
> >  Therefore, we propose to remove the certificate fingerprint parameter (Type 0x03) from the DNS Encryption Parameters Option. 
> >  Instead, clients SHOULD perform standard TLS certificate validation by checking that the server's certificate is valid, chains to a trusted root, and matches the provided Authentication Domain Name (ADN). This method is robust, widely implemented, and handles certificate rotations seamlessly without requiring re-negotiation via IPCP. The security of the encrypted DNS connection is maintained through this standard TLS practice. 
> >  We will remove the corresponding example in Appendix A.3. 
> >  4. Editorial Note on Configuration Priority (Section 3.3) 
> >  Thank you for catching this oversight. 
> >  Our Response & Proposed Text Change: 
> >  The text in Section 3.3 will be updated from: 
> > > "When both Options 129 (RFC 1877) and 133 are present" 
> > to: 
> > > "When both Options 129 (RFC 1877) and 133 or 134 are present" 
> >  We hope these changes effectively address the points you raised. We will incorporate them into the next revision of the draft. Thank you again for your constructive feedback. We welcome further feedback from the community and look forward to continued discussion on this work. 
> >  Best regards, 
> > Dongjie Liu (on behalf of the authors) 
> > Jinan University 
> 
> Thanks! 
> -d 
> 
> 
> > 
> > ---- Replied Message ---- 
> > From Dan Wing<[e-mail]> 
> > Date 10/15/2025 13:07 
> > To dongjieliu8917<[e-mail]> 
> > Cc [e-mail]<[e-mail]>, 
> > [e-mail]<[e-mail]>, 
> > [e-mail]<[e-mail]>, 
> > [e-mail]<[e-mail]> 
> > Subject Re: [Add] Introducing draft-liu-add-ppp-edns-negotiation-00 
> > Does the DNS Encryption Parameters Option (Section 2.3) apply to the Primary encrypted DNS server, the Secondary, or both?  If both, need a way to specify different options for each server. 
> > 
> > Section 3.1 "Client Request Behaviors", "3. The client MAY include Option 135 to request specific parameters" needs additional text how that works. Does the server respond with its best match, or only if they match exactly, or what. 
> > 
> > Certificate pinning:  Both section A.3 section 2.3 involve pinning to a certain certificate: I'm sure you're aware certificate pinning has been effectively abandoned (mostly due to operational complexity). Need discussion how this is overcome.  Needs discussion what occurs if certificate is rotated, is still valid, but now has a different fingerprint. 
> > 
> > 
> > Nit: Section 3.3 "Configuration Priority", 
> > OLD: 
> > When both Options 129 (RFC 1877) and 133 are present 
> > NEW: 
> > When both Options 129 (RFC 1877) and 133 or 134 are present 
> > 
> > 
> > -d 
> > 
> > 
> > 
> >> On Oct 12, 2025, at 9:18 AM, dongjieliu8917 <[e-mail]> wrote: 
> >> 
> >> 
> >> Dear ADD WG, 
> >> 
> >> We'd like to introduce our initial draft: 
> >> Title: PPP IPCP Extensions for Encrypted DNS Server Negotiation 
> >> Document: draft-liu-add-ppp-edns-negotiation-00 
> >> 
> >> This document defines extensions to PPP IPCP for negotiating encrypted DNS resolver configurations (DoT, DoH, DoQ). PPP remains widely used in broadband access, industrial networks, and cellular backhaul, but current IPCP extensions only support plaintext DNS. 
> >> 
> >> The draft defines three new IPCP options: 
> >>     Primary Encrypted DNS Server (Type 133) 
> >>     Secondary Encrypted DNS Server (Type 134) 
> >>     DNS Encryption Parameters (Type 135) 
> >> These enable automatic configuration of encrypted DNS while maintaining backward compatibility with RFC 1877. 
> >> We welcome WG feedback on: 
> >>     The option design and negotiation mechanism 
> >>     Deployment considerations 
> >> 
> >> The draft is available at: 
> >> https://datatracker.ietf.org/doc/draft-liu-add-ppp-edns-negotiation/ 
> >> 
> >> We look forward to your comments. 
> >> 
> >> Best regards, 
> >> Dongjie Liu, Zhiwei Yan, Guanggang Geng, Yinyan Zhang 
> >> 
> >> 
> >> -- 
> >> Add mailing list -- [e-mail] 
> >> To unsubscribe send an email to [e-mail] 
> > 
>