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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 10 Dec 2012 15:09:01 +0000

See http://tools.ietf.org/html/rfc3361 -- this is V4. Not exactly sure why for V6 (RFC 3319) we went for two options instead of similar encoding; likely the answer is that we had plenty of v6 option codes available so there was no reason to conserve (of course, that does result in the other issues I mentioned for that choice).

- Bernie

-----Original Message-----
From: Leaf yeh [mailto:[email-masked]] 
Sent: Monday, December 10, 2012 3:55 AM
To: Bernie Volz (volz)
Cc: [email-masked] WG
Subject: RE: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

Bernie - #3 is pretty clean and explicit. I think Ted would prefer this over #4.

Do we have an example (of Option definition) for solution #3 before?

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, December 07, 2012 10:22 PM
To: Leaf yeh
Cc: [email-masked] WG
Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

Personnally, I don't like that solution - overly complicated.

The possibilities are:
1. only allow one (address or fqdn)
2. two options
3. option with a type field followed by data (address bytes or fqdn wire) 4. option with string (address string or domain name string) 5. rfc 5908 Perhaps there are more?

Note that ideally a list of addresses or fqdns is often best. But in v6, we can have multiple options so that could be solved by doing that.

In general, #1 is what we want people to do - pick one.

#2 has issues in that it may end up that a device only implements support for one, not both options, and a client must request both and server has to return both if configured. (Server could resolve fqdn if client only requests address option not fqdn, but that requires specialized code in server for new options).

#3 is pretty clean and explicit. I think Ted would prefer this over #4.

#4 has been widely discussed as that is what draft proposes.

#5 is as I indicated overly complex. I think the other solutions are preferred.

- Bernie

On Dec 7, 2012, at 3:41 AM, "Leaf yeh" <[email-masked]> wrote:

> Bernie - I think there is a lot of benefit in coming to a conclusion and documenting it. That is why I support the general effort to address this question and come up with an answer - even if it is don't do both, pick one.
> 
> Could the solution described in RFC 5908 be a general one on this topic?
> 
> 
> Best Regards,
> Leaf
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Bernie Volz (volz)
> Sent: Monday, December 03, 2012 8:23 PM
> To: Ted Lemon
> Cc: [email-masked] WG
> Subject: Re: [dhcwg] Call for adoption: 
> draft-boucadair-dhc-address-name-encoding-03
> 
> Ted ... I would hope that one outcoming of this work, if not adopted, would be that the DHC wg would have a strong recommendation (requirement?) that new drafts that require a fqdn/address MUST pick one? Thus, I think there is a lot of benefit in coming to a conclusion and documenting it. That is why I support the general effort to address this question and come up with an answer - even if it is don't do both, pick one.
> 
> I don't share most of your concerns (with DHCP there are a lot eaiser attack vectors than trying to inject some junk into this option data, for example).
> 
> I don't believe there is an attempt to support dual-stack addresses with this? I raised v4 addresses because I think this solution, if used, should apply to new v4 options and in that context v4 addresses should be valid.
> 
> - Bernie
> 
> 
>> 
>> 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.
>> 
>> This is why I do not support this work.
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg___________________________
> ____________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg