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

From: Tina TSOU <[email-masked]>
Date: Mon, 3 Dec 2012 07:08:43 +0000

Dear all,
Support draft-boucadair-dhc-address-name-encoding-03 being adopted as WG item.
My comments on the previous version to the authors have been addressed in this version.

Thank you,
Tina

On Nov 30, 2012, at 7:23 AM, "[email-masked]" <[email-masked]> wrote:

> 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.
>> 
>> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 3 Dec 2012 12:22:54 +0000

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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Leaf yeh <[email-masked]>
Date: Fri, 7 Dec 2012 08:41:17 +0000

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

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Dec 2012 14:21:54 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Dec 2012 14:27:53 +0000

> 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…

As I said to Bernie, this question is in scope for draft-ietf-dhc-option-guidelines, which is already a working group document, so there is no need to adopt a new working group document simply for the purpose of addressing this issue.

The reason to support or oppose Med's work here is that you either agree that his proposed new way of solving the problem is a good idea, or you think it's a bad idea.   If you just want *some* solution to the problem, we already have one.

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 7 Dec 2012 09:50:02 -0500

To follow along where (I imagine) Ted was going, I would like to see Bernie's

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

added to draft-ietf-dhc-option-guidelines.  I think the order in the
list above is the correct ordering for the desirability of each
solution.  I hope that someone will pull together the reasoning
for or against each approach and add it to that draft. Almost
certainly the text for this already resides in this email thread,
though it will take work to pull it together.

I think #4 will cause more problems long-term than it will solve,
so I am not in favor of *anyone* using that approach.  Because of
my position on that approach, I certainly am not in favor of adopting
a draft as a WG work item whose goal it is suggest that as a 
generally applicable approach.

Regards -- Kim

---

From: <[email-masked]>
Date: Fri, 7 Dec 2012 16:10:31 +0100

Dear Kim,

It seems there is a confusion. The approach proposed in draft-boucadair-* is as follows (excerpt from the draft):

(1) New DHCP options SHOULD use either an IP-Address or FQDN encoding for
   the data.  If there is a strong requirement to support both an IP-
   Address and FQDN encoding, the option specification MUST use the
   encoding specified in this document and MUST provide the rationale to
   motivate why either an IP-Address or FQDN encoding is insufficient.

(2) The document defines one single option which is encoded as UTF-8 string.

This call is whether you support or not that approach.

Cheers,
Med

>la part de Kim Kinnear
>Envoyé : vendredi 7 décembre 2012 15:50
>À : Ted Lemon; [email-masked] WG
>Cc : Bernie Volz (volz); Kim Kinnear
>>> 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.
>> 
>> As I said to Bernie, this question is in scope for 
>draft-ietf-dhc-option-guidelines, which is already a working 
>group document, so there is no need to adopt a new working 
>group document simply for the purpose of addressing this issue.
>> 
>> The reason to support or oppose Med's work here is that you 
>either agree that his proposed new way of solving the problem 
>is a good idea, or you think it's a bad idea.   If you just 
>want *some* solution to the problem, we already have one.
>>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Dec 2012 15:11:10 +0000

> though it will take work to pull it together.

Thanks, Kim.   Yes, I like Bernie's summary, and agree with you about option 4 (and with him about option 3).   I read over the text about FQDNs in the current draft, and it could certainly stand to be expanded with a lot of what we've been talking about here.

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 7 Dec 2012 17:53:35 -0500

Med,

> The reason to support or oppose Med's work here is that you either agree that his proposed new way of solving the problem is a good idea, or you think it's a bad idea.   If you just want *some* sol…

I think it is a bad idea.  So...

Now, perhaps you are saying "Yes, it is a bad idea, but if you
*really* *have* to do this bad thing, here is the option
definition that you should use to do this bad thing."  

...

So, I am feeling a bit of a disconnect between what you are
saying and what Ted is saying about what it means to support
adopting this draft as a WG work item.  

That said, doesn't having this option already defined make it
easier for people to use this approach in future drafts?

If yes, isn't that a reason to *not* do this draft?

Regards -- Kim

---

From: <[email-masked]>
Date: Mon, 10 Dec 2012 08:50:38 +0100

Dear Kim,

I'm not saying it is a bad idea. I sincerely think it is a ** simple ** solution which ** solve ** a valid problem. 

I disagree with Ted there is already a solution for this problem: choosing between an FQDN or an IP address is ** not ** a solution for some contexts (options). Ted's approach assumes the DHCP server has interfaces to all service-logics enabled in an administrative domain (e.g, to service-specific DNS infrastructure, to all service load-balancing functions, etc.) and also ignores operational constraints (e.g., network/service separation, two-level indirection, etc.).

The approach proposed in this document can be enabled in scenarios where Ted' assumptions are valid ** but ** also for the other deployment contexts.

The proposed approach does not require defining two options to provision the same parameter but only one single option is needed. 

Because some of the WG participants see as a risk this approach will be generalized and adopted as de facto format, draft-boucadair-* recommends option designers to motivate why an IP Address only or FQDN only format can not meet their requirements. It seems to me this is pragmatic approach.

Cheers,
Med 

>De : Kim Kinnear [mailto:[email-masked]] 
>Envoyé : vendredi 7 décembre 2012 23:54
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Kim Kinnear; Ted Lemon; [email-masked] WG; Bernie Volz (volz)
>> It seems there is a confusion. The approach proposed in 
>draft-boucadair-* is as follows (excerpt from the draft):
>>

---

From: Leaf yeh <[email-masked]>
Date: Mon, 10 Dec 2012 08:54:30 +0000

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

The possibilities are:

- Bernie

---

From: Leaf yeh <[email-masked]>
Date: Mon, 10 Dec 2012 09:14:01 +0000

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?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kim Kinnear
Sent: Friday, December 07, 2012 10:50 PM
To: Ted Lemon; [email-masked] WG
Cc: Bernie Volz (volz); Kim Kinnear
Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

Regards -- Kim

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 10 Dec 2012 15:19:49 +0100

> 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:

> 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)

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.

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 10 Dec 2012 16:17:06 +0100

> want to standardize that.
One argument I don't see here: Could resolution be intended to happen
when the client actually uses that data? My point is - it could have
changed between the server doing resolution and the need in the client?

Just a thought for completeness. I don't have specific use cases.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Dec 2012 15:18:05 +0000

> I disagree with Ted there is already a solution for this problem: choosing between an FQDN or an IP address is ** not ** a solution for some contexts (options). Ted's approach assumes the DHCP serv…

So you're saying that one of the motivations for this draft is operation in a split-horizon DNS environment?   If so, why wouldn't an option that contains an FQDN address that use case?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Dec 2012 15:25:53 +0000

> Does this sound reasonable?

In general I'm in agreement with this approach, but I would like to know what you mean by (2).   Are you saying that we should in fact offer the address/name text encoding as an alternative in the option guidelines draft?   Because I strongly oppose this, both for reasons you've stated and for additional reasons I've stated separately.   If you just mean that we should offer a way to solve Med's problem in an option, but not as a text string, then I'm fine with that, as long as it's expressed as a "only do this when there is a clear motivating use case not addressed by FQDN or IP address alone" kind of alternative.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Dec 2012 15:27:33 +0000

On Dec 10, 2012, at 10:17 AM, Sten Carlsen <[email-masked]>
 wrote:
> One argument I don't see here: Could resolution be intended to happen when the client actually uses that data? My point is - it could have changed between the server doing resolution and the need in the client?

This would be addressed by FQDN alone—no need for Med's proposed encoding.   Also, it's a pretty unlikely scenario, since DHCP renewals can happen pretty frequently, and do not happen at predictable times.

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 10 Dec 2012 10:40:13 -0500

Tomek,

That sounds like a good plan to me.

Regards -- Kim

---

From: <[email-masked]>
Date: Mon, 10 Dec 2012 17:06:04 +0100

Hi Tomek,

There is already some text about validation in the address-name-encoding draft:

"    A Name is considered as valid if:

      *  It is a legal UTF-8 string which does not contain any spaces
         nor nulls.
      *  It contains IPv4 address in dotted-decimal form (e.g.,
         192.0.2.33), textual representation of an IPv6 address (e.g.,
         2001:db8::1) [RFC4291] [RFC5952] or a domain name (e.g.,
         "myservice.example.com")[RFC2181].  Note:
         +  The trailing dot is optional when a domain name is conveyed
            in the option.
         +  IPv6 addresses MUST NOT be enclosed in brackets.
         +  A domain name is structured as one or more labels
            concatenated with dots.  A label MUST NOT be no more than 63
            characters."

Some of the cases you mentioned can be handled by the name resolution library itself. 

As for the security issue you mentioned, I must admit I'm unable to judge its severity and if this is specific to this encoding (see for example this security alarm http://securitytracker.com/id/1009368).

Could you please indicate which ordering you are suggesting to include in the guideline draft? Thanks. 

Cheers,
Med

>la part de Tomek Mrugalski
>Envoyé : lundi 10 décembre 2012 15:20
>À : [email-masked]
>> Kim - I think the order in the list above is the correct 
>ordering for the desirability of each solution.
>>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Dec 2012 09:16:17 +0100

Hi Leaf,

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

I don't know about domains but for timezones we ended up with multiple
options just to flatten things.  That made for even EASIER parsing ;-) 
I don't know if that logic would hold for all circumstances, tho.  The
key thing that DOES hold (IMHO) is use of types.

Eliot