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:37:50 +0000

Tomek:

Regarding "Depending on the implementation, parsing nested option is sometimes very easy thing to do", I wasn't really worried about the client parsing. What wasn't that nice was the server's user interface for configuring this. That was actually why I lowered its preference. I can also envision that over time additional choices might be added to the mix and that would just further complicate the user interface for this -- one nice UI would be to allow the user to enter either an address or FQDN and have the UI figure it out ... oh wait ...

Regarding the address-name-encoding issue (which ties into above UI issue), I think we would want to keep it simple in that only a limited set of syntaxes would be fully interoperable. If the DHCP server administrator entered 0x4a7d8864, I would not expect that to work across all clients (whereas 74.125.136.100) would. We would also be clear that no special characters such as [ and ] would be included for addresses.

Yes, allowing a free form text string could cause invalid or unexpected results or even allow someone to perform something malicious (perhaps get root access). I think we can protect fairly well against this. I would think the parsing at the client would be no different than what would be expected when entering a domain name or address to another application.

While I agree it may be possible that there could be attacks using this, I would think that if you can hijack DHCP you'd have many avenues available for attacks.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Monday, December 10, 2012 9:20 AM
To: [email-masked]
Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

On 10.12.2012 10:14, Leaf yeh wrote:
> Kim - I think the order in the list above is the correct ordering for the desirability of each solution.
> 
> That sound you prefer #1 (Address?), then let the Server help to resolve the FQDN. Right?
Yes. The server allowing user to specify fqdn is an implementation detail here. Depending on the way a server is implemented, that resolution may happen when user enters the fqdn for the first time, when the server is started or immediately before sending a response to a client. These are all implementation details and we definitely don't want to standardize that.

As for the list or options, here are my comments:

The possibilities are:
> 1. only allow one (address or fqdn)
There is already a discussion about trade-offs between them, both in address-name-encoding and option-guidelines (with address-name-encoding discussion being more thorough IMHO). In general, address is preferred unless that are valid reasons for fqdn. For the clarify, we may split it into two possibilities, with address being listed first. And it's often address list vs fqdn list, but that's really a nit pick.

> 2. two options
Been there, tried that. See RFC6334 (DS-Lite option). IESG laughed at us and said to make up our minds and just pick one. Perhaps we were unable to produce convincing enough arguments for both options, but in my opinion that approach is very unlikely to complete standardization process.

Just for your convenience, here's a brief list of issues that we've encountered. This approach introduces some ugly problems without any good solutions. Should client request both options? If both are returned, which one should be used? Both? In what order? What about the other one? Is it discarded or kept as a backup value? This introduces solution specific questions about failover type solutions. What if client requests one option, but gets the other? Should authors add a statement that clients and servers MUST implement both? If only one is mandatory and the other is optional, which one is mandatory? What if client requests one and receives the other that it does not support?
When server receives a request for both, should it send back both if configured with values for both?

Regardless of which answers you choose, you'll break down some basic principles DHCPv6 is operating on. In summary, that's a mess that you
*really* want to avoid.

> 3. option with a type field followed by data (address bytes or fqdn 
> wire)
option-guidelines draft recommends against conditional formatting. We may put this as a viable option, but we should clearly mark it as a lesser evil.

> 4. option with string (address string or domain name string) 5. rfc 
> 5908

I would recommend swapping the order of RFC5908 (nested options) with option with a string, but I won't object to the order proposed by Bernie. Depending on the implementation, parsing nested option is sometimes very easy thing to do. Also, there are two sub-cases of
RFC5908 approach: you can either use new option space (sub-options start with 1, 2, 3...) or you can put normal options as nested options within some container option (with the nested options getting regular numbers, like 79, 80 and onwards). The latter is a very similar to possibility #2.

Personally I have a couple objections to address-name-encoding, with one being serious. First, this proposal has a significant problem with the validation. You allow configuring domains, IPv4 literals and IPv6 literals. But in which format? Normal IPv6 text format is obvious, but what about IPv4-mapped IPv6 addresses and other odd, exotic notations?
Let me give you an example:
"www.google.com" is obviously valid. "74.125.136.100" is still valid, right? But what about "0x4a7d8864"? All browsers I have around will turn this into IPv4 address, which will happen to be 74.125.136.100. I guess (haven't checked, so it's just a guess) that getaddrinfo() just resolves it to the address. Do you allow that? What about corner cases, like 1.2.3.256?

Section 3 of the draft says "The DHCP client decoding an option in this format MUST validate the contents of the option.". An honest question as a DHCP implementor: how am I supposed to write a validation of such string?

Blindly passing the content to getaddrinfo() will open nice remote attack vector in case there are issues with getaddrinfo() implementation.

Second issue is about efficiency - sending address as 16 bytes is more efficient than as a string that is potentially as long as 45 bytes. This is even more important if we decide to allow it in DHCPv4. Note that this document currently proposes to do so.

Of course that format also brings in the issues FQDN has with all the failure modes: DNS not available, not responding, having only A when you want AAAA (or vice versa), etc. There may be less obvious failure modes as draft-boucadair-dhc-address-name-encoding explicitly mentions that other resolution mechanisms may be used.

To summarise my opinion, I object adoption of this draft. My main objection is that it will give a wrong signal to people, who don't follow DHC too closely. They will likely just look that it's DHC draft, so they'll start using this approach.

But this is not a "forget it" type of objection. This draft tries to solve a problem that is real and is quite frequently encountered. This draft also has a lot of very thoughtful text about benefits and downsides of various approaches. Here's what I recommend:

1. document Bernie's proposal in draft-ietf-dhc-option-guidelines.
2. merge parts of draft-boucadair-dhc-address-name-encoding into draft-ietf-dhc-option-guidelines.
3. publish updated option-guidelines and last call it?

Does this sound reasonable?

Tomek

p.s.
option-guidelines-09 will expire in 8 days. We need to update it one way or the other.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 10 Dec 2012 17:35:34 +0100

On 10.12.2012 16:37, Bernie Volz (volz) wrote:
> Regarding "Depending on the implementation, parsing nested option is
> sometimes very easy thing to do", I wasn't really worried about the
> client parsing. What wasn't that nice was the server's user interface
> for configuring this. That was actually why I lowered its preference.
> I can also envision that over time additional choices might be added
> to the mix and that would just further complicate the user interface
> for this -- one nice UI would be to allow the user to enter either an
> address or FQDN and have the UI figure it out ... oh wait ...
:)

> Regarding the address-name-encoding issue (which ties into above UI
> issue), I think we would want to keep it simple in that only a
> limited set of syntaxes would be fully interoperable. If the DHCP
> server administrator entered 0x4a7d8864, I would not expect that to
> work across all clients (whereas 74.125.136.100) would. We would also
> be clear that no special characters such as [ and ] would be included
> for addresses.
I was just an example, perhaps not a good one. I was not suggesting that
those particular examples should or should not be allowed, just trying
to point out that proposed text is vague and I don't see any simple way
to make it more precise. Requirements from section 3 allow any UTF-8
text without spaces and nulls. According to current text, the following
are valid names: foo@#$!%^&*#@, "\t\t\n", (a series of random bytes that
is not equal to 0 or 32). Even if you extend the definition (replace
"The Name MUST NOT contain spaces or nulls." from Section 3 with
something more precise), you head into other problems with UTF-8. There
are many types of hyphens, dashes and minuses and similar looking
characters and that's all even without leaving Europe. Now think about
folks in Asia (or Poland for that matter - we do have accented
characters over here. Yes, we do have upper-case and lower-case for
them.). I have no idea how to code a validation what is a proper
Chineese, Korean or Japanese name and what is not. The draft does not
give me any clues in that regard, but requires me to validate it anyway
("The DHCP client decoding an option in this format MUST validate the
contents of the option.").

> Yes, allowing a free form text string could cause invalid or
> unexpected results or even allow someone to perform something
> malicious (perhaps get root access).
Having one server compromised in your network is a bad thing. But if an
attacker can easily escalate that into root access on all your hosts,
then suddenly DHCPv6 servers will become primary targets in all networks.

> I think we can protect fairly well against this.
How? We can pass received content of the option to getaddrinfo and hope
that OS vendor did his job well. We could reject invalid strings, but
deciding what is valid and what is not is a non-trivial problem. Do you
have any other alternatives in mind?

> I would think the parsing at the client would be
> no different than what would be expected when entering a domain name
> or address to another application.
Current domain encoding is straight-forward and allows only latin
alphabet, with nice and easy isascii, isalpha, isdigit etc. calls at
your disposal. This draft proposes UTF-8, which is way beyond that.

> While I agree it may be possible that there could be attacks using
> this, I would think that if you can hijack DHCP you'd have many
> avenues available for attacks.
Having your DHCP server compromised is likely to ruin your day, I agree. :)

To summarize my point: lack of firm rules for validation of received
option is a serious drawback of this approach. It is not a showstopper,
but it causes that this approach should be used as a last resort, when
every other solution is not suitable.

On a related topic, IDN is probably yet another topic for 3315bis.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Dec 2012 16:40:20 +0000

> On a related topic, IDN is probably yet another topic for 3315bis.

It's worth noting that IDN is already addressed by 3315, because the FQDN format in 3315 is a binary format—we've neatly sidestepped any issues with text representations because we don't currently specify any text representation.   This was a deliberate choice when we wrote 3315, which was carried forward from related work done for DHCPv4.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 10 Dec 2012 16:45:44 +0000

Tomek:

I had proposed that we require the string to be the IDN ACE encoding so that it would follow a much more restricted character set (ASCII subset?). I think we want this to be basically the string from of the (well formed) FQDN. I don't know if that requires UTF-8 or just plain (7-bit) ASCII?

I agree that we don't want this to be the 'raw' native language UTF-8 string for what an administrator might have entered.

But, it could be that I know not what I talk about.

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Monday, December 10, 2012 11:36 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

:)

> issue), I think we would want to keep it simple in that only a limited 
> set of syntaxes would be fully interoperable. If the DHCP server 
> administrator entered 0x4a7d8864, I would not expect that to work 
> across all clients (whereas 74.125.136.100) would. We would also be 
> clear that no special characters such as [ and ] would be included for 
> addresses.
I was just an example, perhaps not a good one. I was not suggesting that those particular examples should or should not be allowed, just trying to point out that proposed text is vague and I don't see any simple way to make it more precise. Requirements from section 3 allow any UTF-8 text without spaces and nulls. According to current text, the following are valid names: foo@#$!%^&*#@, "\t\t\n", (a series of random bytes that is not equal to 0 or 32). Even if you extend the definition (replace "The Name MUST NOT contain spaces or nulls." from Section 3 with something more precise), you head into other problems with UTF-8. There are many types of hyphens, dashes and minuses and similar looking characters and that's all even without leaving Europe. Now think about folks in Asia (or Poland for that matter - we do have accented characters over here. Yes, we do have upper-case and lower-case for them.). I have no idea how to code a validation what is a proper Chineese, Korean or Japanese name and what is not. The draft does not give me any clues in that regard, but requires me to validate it anyway ("The DHCP client decoding an option in this format MUST validate the contents of the option.").

> malicious (perhaps get root access).
Having one server compromised in your network is a bad thing. But if an attacker can easily escalate that into root access on all your hosts, then suddenly DHCPv6 servers will become primary targets in all networks.

> I think we can protect fairly well against this.
How? We can pass received content of the option to getaddrinfo and hope that OS vendor did his job well. We could reject invalid strings, but deciding what is valid and what is not is a non-trivial problem. Do you have any other alternatives in mind?

> I would think the parsing at the client would be no different than 
> what would be expected when entering a domain name or address to 
> another application.
Current domain encoding is straight-forward and allows only latin alphabet, with nice and easy isascii, isalpha, isdigit etc. calls at your disposal. This draft proposes UTF-8, which is way beyond that.

To summarize my point: lack of firm rules for validation of received option is a serious drawback of this approach. It is not a showstopper, but it causes that this approach should be used as a last resort, when every other solution is not suitable.

Tomek

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 08:06:13 +0100

Hi Tomek,
 
Please see inline. 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Tomek Mrugalski
>Envoyé : lundi 10 décembre 2012 17:36
>À : Bernie Volz (volz)
>Cc : [email-masked]
>Objet : Re: [dhcwg] Call for adoption: 
>draft-boucadair-dhc-address-name-encoding-03
>

Med: I have considered updating the text with more validation rules (in addition to the ones already listed in -03 of the draft), but after reading the following (excerpt from RFC6055) I decided to not add more rules:

   By 1997, things had progressed to a state where it was necessary to
   clarify these areas of confusion.  "Clarifications to the DNS
   Specification" [RFC2181], Section 11 states:

      The DNS itself places only one restriction on the particular
      labels that can be used to identify resource records.  That one
      restriction relates to the length of the label and the full name.
      The length of any one label is limited to between 1 and 63 octets.
      A full domain name is limited to 255 octets (including the
      separators).  The zero length full name is defined as representing
      the root of the DNS tree, and is typically written and displayed
      as ".".  Those restrictions aside, any binary string whatever can
      be used as the label of any resource record.  Similarly, any
      binary string can serve as the value of any record that includes a
      domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
      and any others that may be added).  Implementations of the DNS
      protocols must not place any restrictions on the labels that can
      be used.

   Hence, it clarified that the restriction to letters, digits, and
   hyphens does not apply to DNS names in general, nor to records that
   include "domain names".  Hence, the "preferred" name syntax described
   in the original DNS specification [RFC1034] is indeed merely
   "preferred", not mandatory.

   Since there is no restriction even to ASCII, let alone letter-digit-
   hyphen use, DNS does not violate the subsequent IETF requirement to
   allow UTF-8 [RFC2277].

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 08:06:37 +0100

Dear Bernie,

FWIW, when I was preparing -03 of the draft I have considered integrating your comment (use IDN ICE) but after re-reading RFC2181 and RFC6055 in particular, I added only the following:

         +  A domain name is structured as one or more labels
            concatenated with dots.  A label MUST NOT be no more than 63
            characters.

Do you agree/disagree with my interpretation of the those RFCs?

Cheers,
Med 

>la part de Bernie Volz (volz)
>Envoyé : lundi 10 décembre 2012 17:46
>À : Tomek Mrugalski
>Cc : [email-masked]
>I had proposed that we require the string to be the IDN ACE 
>encoding so that it would follow a much more restricted 
>character set (ASCII subset?). I think we want this to be 
>basically the string from of the (well formed) FQDN. I don't 
>know if that requires UTF-8 or just plain (7-bit) ASCII?
>
>I agree that we don't want this to be the 'raw' native 
>language UTF-8 string for what an administrator might have entered.
>
>Subject: Re: [dhcwg] Call for adoption: 
>I was just an example, perhaps not a good one. I was not 
>suggesting that those particular examples should or should not 
>be allowed, just trying to point out that proposed text is 
>vague and I don't see any simple way to make it more precise. 
>Requirements from section 3 allow any UTF-8 text without 
>spaces and nulls. According to current text, the following are 
>valid names: foo@#$!%^&*#@, "\t\t\n", (a series of random 
>bytes that is not equal to 0 or 32). Even if you extend the 
>definition (replace "The Name MUST NOT contain spaces or 
>nulls." from Section 3 with something more precise), you head 
>into other problems with UTF-8. There are many types of 
>hyphens, dashes and minuses and similar looking characters and 
>that's all even without leaving Europe. Now think about folks 
>in Asia (or Poland for that matter - we do have accented 
>characters over here. Yes, we do have upper-case and 
>lower-case for them.). I have no idea how to code a validation 
>what is a proper Chineese, Korean or J
> apanese name and what is not. The draft does not give me any 
>clues in that regard, but requires me to validate it anyway 
>("The DHCP client decoding an option in this format MUST 
>validate the contents of the option.").
>
>Having one server compromised in your network is a bad thing. 
>But if an attacker can easily escalate that into root access 
>on all your hosts, then suddenly DHCPv6 servers will become 
>primary targets in all networks.
>
>How? We can pass received content of the option to getaddrinfo 
>and hope that OS vendor did his job well. We could reject 
>invalid strings, but deciding what is valid and what is not is 
>a non-trivial problem. Do you have any other alternatives in mind?
>
>Current domain encoding is straight-forward and allows only 
>latin alphabet, with nice and easy isascii, isalpha, isdigit 
>etc. calls at your disposal. This draft proposes UTF-8, which 
>is way beyond that.
>
>To summarize my point: lack of firm rules for validation of 
>received option is a serious drawback of this approach. It is 
>not a showstopper, but it causes that this approach should be 
>used as a last resort, when every other solution is not suitable.
>