Subject: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 15:07:18 +0000

Med has asked for a call for adoption to gauge working group consensus as to whether we should work on his proposal.   The consensus we are trying to get here is, is it a good idea have a DHCP option format that is a text representation of either a name or an IP address, and to recommend the use of this format to address some use cases that might arise in the development of future DHCPv6 options.

To be clear, this is not a consensus call on whether we should have an option format representation for FQDNs: we already have one.   It is not even a consensus call on whether we should be able to have options that carry both FQDNs and IP addresses—there's already an example of such an option in the ntp option document.

This is specifically about using a UTF-8 string to carry either an FQDN or an IP address.

If you think the working group should define such an option format, please reply to this message saying so.   If you think the working group should not, please also reply saying so.   If you have no opinion, there is no need to respond.   We will evaluate consensus on December 14.

Thanks!

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 15:14:16 +0000

My response to this call for adoption, wearing my working group participant hat, not my working group chair hat, is that I strongly oppose adoption of this work.

A number of arguments have been raised in favor of doing this work, and I've attempted to state my considered opinion on them below:

The DHC working group long ago decided not to put dual-stack transition technology into DHCPv6.   So if the motivation for using an FQDN is dual-stack transition, this is not a good argument.   And if the motivation for using a text representation of an IPv6 address is dual-stack transition, again this is not a good argument.

Similarly, the argument has been made that the FQDN+IP option format is necessary to support certain deployment strategies that are already adequately addressed by existing technology.   This again is not a good argument—if the existing standards already support the functionality that is needed, then there is no need to extend the standards.

A specific use case has been raised where the same domain name returns different results (that is to say, completely different sets of addresses) depending on the location from which the query is done.   And that we have to extend DHCPv6 to support this use case.   But this isn't a valid use case at all, because standards-compliant DNS does not return completely different values depending on location.   If it did, this would break all kinds of things—DNSSEC, tunnels, standards-compliant local caching servers.

I know that this sort of thing is done all the time in CDNs, but the fact that people do it in the wild is not a reason to put it in an IETF standard.

With regard to validation, the author referred to RFC2181, which says the content of labels is not restricted.   But this doesn't help, because we are not talking about the content of labels—we are talking about a human-readable presentation of the content of labels, with an undefined transform between the one and the other.   No document defines this transformation.   This is why we chose to use the wire-format representation for FQDNs in DHCP.

So the bottom line is that there are a lot of really weak arguments for adding this complexity to DHCP.   But this proposal adds significant complexity.   I spent an hour yesterday doing a fairly thorough review of the existing documents that talk about the text representation for DNS, and was unable to identify a document that specifies how to validate the text representation of a domain name, although many different documents talk about aspects of how domain names are represented as text.

So this proposal adds a very real attack surface to any service that uses this option format.  There's no standard for validation that, if followed, would eliminate that attack surface.  And there's no compelling use case to motivate adding it.

This is why I do not support this work.

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 16:23:08 +0100

Re-

FWIW, the latest version of the draft is available here: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-03

As this is a call for adoption, I would avoid answering the message below from Ted.

Unlike Ted, I strongly support the WG adopting this alternative encoding scheme which is restricted to the following scope: deployment context where both an IP address and FQDN are needed. The proposed approach requires new options to justify why an IP-Address only or FQDN-only option does not meet their requirement. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Ted Lemon
>Envoyé : vendredi 30 novembre 2012 16:14
>À : [email-masked] WG
>Objet : Re: [dhcwg] Call for adoption: 
>draft-boucadair-dhc-address-name-encoding-03
>
>My response to this call for adoption, wearing my working 
>group participant hat, not my working group chair hat, is that 
>I strongly oppose adoption of this work.
>
>A number of arguments have been raised in favor of doing this 
>work, and I've attempted to state my considered opinion on them below:
>
>The DHC working group long ago decided not to put dual-stack 
>transition technology into DHCPv6.   So if the motivation for 
>using an FQDN is dual-stack transition, this is not a good 
>argument.   And if the motivation for using a text 
>representation of an IPv6 address is dual-stack transition, 
>again this is not a good argument.
>
>Similarly, the argument has been made that the FQDN+IP option 
>format is necessary to support certain deployment strategies 
>that are already adequately addressed by existing technology.  
> This again is not a good argument-if the existing standards 
>already support the functionality that is needed, then there 
>is no need to extend the standards.
>
>A specific use case has been raised where the same domain name 
>returns different results (that is to say, completely 
>different sets of addresses) depending on the location from 
>which the query is done.   And that we have to extend DHCPv6 
>to support this use case.   But this isn't a valid use case at 
>all, because standards-compliant DNS does not return 
>completely different values depending on location.   If it 
>did, this would break all kinds of things-DNSSEC, tunnels, 
>standards-compliant local caching servers.
>
>I know that this sort of thing is done all the time in CDNs, 
>but the fact that people do it in the wild is not a reason to 
>put it in an IETF standard.
>
>With regard to validation, the author referred to RFC2181, 
>which says the content of labels is not restricted.   But this 
>doesn't help, because we are not talking about the content of 
>labels-we are talking about a human-readable presentation of 
>the content of labels, with an undefined transform between the 
>one and the other.   No document defines this transformation.  
> This is why we chose to use the wire-format representation 
>for FQDNs in DHCP.
>
>So the bottom line is that there are a lot of really weak 
>arguments for adding this complexity to DHCP.   But this 
>proposal adds significant complexity.   I spent an hour 
>yesterday doing a fairly thorough review of the existing 
>documents that talk about the text representation for DNS, and 
>was unable to identify a document that specifies how to 
>validate the text representation of a domain name, although 
>many different documents talk about aspects of how domain 
>names are represented as text.
>
>So this proposal adds a very real attack surface to any 
>service that uses this option format.  There's no standard for 
>validation that, if followed, would eliminate that attack 
>surface.  And there's no compelling use case to motivate adding it.
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg
>