Subject: Re: [CDNi] IPv4 Litteral Re: CDNI Requirements I-D

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 14 Mar 2011 14:21:27 +0100

Folks,

Here is the generic requirement I drafted to reflect this discussion:

"
When making use of third party reference, the CDNI solution MUST consider the potential issues associated with the use of various format of third-party references (e.g. NAT or IPv4/IPv6 translation potentially breaking third-party references based on an IP addresses such as URI containing IPv4 or IPv6 address litterals, split DNS situations potentially breaking third-party references based on DNS fully qualified domain names) and wherever possible avoid, minimize or mitigate the associated risks based on the specifics of the environments where the reference is used (e.g. likely or unlikely presence of NAT in the path). In particular, this applies to situations where the CDNI solution needs to construct and convey uniform resource identifiers for directing/redirecting a content request, as well as to situations where the CDNI solution needs to pass on a third party reference (e.g. to identify a User Agent) in order to allow another entity to make a more informed decision (e.g. make a more informed request routing decision by attempting to derive location information from the third party reference). 
"

I suspect this can be improved, so suggestions are welcome.

Francois

On 3 Feb 2011, at 13:24, David R Oran wrote:

> 
> On Feb 3, 2011, at 5:47 AM, Francois Le Faucheur wrote:
> 
>> David, Yiu,
>> 
>> On 3 Feb 2011, at 00:29, David R Oran wrote:
>> 
>>> 
>>> On Feb 2, 2011, at 1:28 PM, Lee, Yiu wrote:
>>> 
>>>> Hi Dave,
>>>> 
>>>> Let me clarify what I try to say. In the current requirement draft, we
>>>> specifically gave example to include IP address. This is why Dan replied
>>>> warning us this would break NAT64. IMHO, we should remove those examples
>>>> to have IP address. I am ok with your suggestion (ie third-party
>>>> reference), but I would like to give some examples such as FQDN, URN, etc
>>>> and remove IP address from the current example.
>>>> 
>>> I agree that giving examples of problematic URI forms, including those that cause third-party reference problems, would be a good addition to the document.
>> 
>> I have the impression you two are talking slightly past each other (unless it is me that is past the two of you).
>> 
>> I believe Yiu is making the point that the current Requirements document includes an example of IP address being used as a reference (Yiu, I assume you refer to R35 in particular?). This was intended to be a positive example, so it now seems like a real bad example and should be changed to a better example (eg FQDN).
>> 
> Ok.
> 
>> I believe David is making the point that, alongside the new requirement to be added along the lines of ... the CDNI solution MUST "only use URI's that work as third-party references", it would be useful to provide an example of what is a broken 3rd party reference (eg because it is based on IP address).
>> 
> Yes.
> 
>> If I got this right, both points seem valid.
>> 
> Yes.
> 
>> David, is there some document that can be referenced to help folks understand what it means "to work as a third-party reference"?
>> 
> I've never seen this all gathered up in one place, aside from even more general architecture papers that talk about "transparency" and "end-to-end". If the net were transparent as it's original architects envisioned then we would not be having this discussion because third-party references, using either addresses or names, would always work.
> 
> I'll ask around though.
> 
>> Thanks
>> 
>> Francois
>> 
>> 
>>> I myself was remiss in being so terse and not giving examples myself in my email.
>>> 
>>> Thanks for the thoughtful reply.
>>> 
>>> I was mostly aiming at ensuring that we didn't just laser-focus on IP addresses as problematic in URIs since sometimes they are and sometimes they aren't. Just banning IP addresses from URIs used in CDNi is attacking only one manifestation of the problem
>>> 
>>> Incidentally, a good example of where FQDNs can also go astray is the split-DNS situation I previously alluded to. When you have split DNS, servers in one domain may return different results from servers in other domains, or potentially fail to return any useful results. This may in fact be a real problem in CDNi situations as service providers (and sometimes enterprises as well) are sometimes enticed by the supposed benefits of using split-DNS techniques to hide the names of internal resources. Another example I might raise (with some trepidation) is "carrier ENUM" where the DNS FQDNs for phone numbers resolve differently (or not at all) in different SP networks.
>>> 
>>> DaveO
>>> 
>>> 
>>> 
>>>> Cheers,
>>>> Yiu
>>>> 
>>>> 
>>>> On 2/2/11 9:49 AM, "David R Oran" <[email-masked]> wrote:
>>>> 
>>>>> 
>>>>> On Feb 1, 2011, at 11:32 PM, Lee, Yiu wrote:
>>>>> 
>>>>>> Agreed and we didn't write a requirement that would lead to any specific
>>>>>> technology. All we are saying is that the the Content-Location would
>>>>>> contain FQDN. That's it.
>>>>>> 
>>>>> I don't follow your reasoning. Saying that is neither necessary (since in
>>>>> many cases addresses will work), nor sufficient (because in a number of
>>>>> cases like split DNS an FQDN will not work).
>>>>> 
>>>>> I think the requirement is that "people only use URI's that work as
>>>>> third-party references".
>>>>> 
>>>>> This is a difficult area, admittedly, but writing requirements that don't
>>>>> capture the underlying problem to be solved isn't all that helpful since
>>>>> in hindsight people will inevitably forget why the requirement existed.
>>>>> 
>>>>> Now, if you want to mandate only FQDNs for some other reason that's fine,
>>>>> but do you want to close the door to someday having a CDN-friendly URNs
>>>>> instead of URIs anyway.
>>>>> 
>>>>> DaveO.
>>>>> 
>>>>>> On 2/1/11 7:47 PM, "David R Oran" <[email-masked]> wrote:
>>>>>> 
>>>>>>> Isn't this a special case of the general 3rd party referral problem?
>>>>>>> Why
>>>>>>> are you writing CDNi-specific requirements? Shouldn't you just say "CDN
>>>>>>> interconnection requires third party references and hence depends on
>>>>>>> mechanisms for the handling of such in URI's for a number of cases
>>>>>>> involving NATs, V4/V6 tunnels, and other scenarios that cause problems
>>>>>>> with third party references".
>>>>>>> 
>>>>>>> I would hate to see a requirement that led to a custom solution for CDN
>>>>>>> interconnection that didn't work for any old style of redirection.
>>>>>>> 
>>>>>>> If IP address literals cause third-party breakage, just banning them
>>>>>>> will
>>>>>>> only mask problems when people add further breakage like split DNS.
>>>>>>> 
>>>>>>> DaveO
>>>>>>> 
>>>>>>> On Feb 1, 2011, at 2:06 PM, Francois Le Faucheur wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On 1 Feb 2011, at 19:58, Lee, Yiu wrote:
>>>>>>>> 
>>>>>>>>> Hi Ben,
>>>>>>>>> 
>>>>>>>>> Thanks for thinking through this. My concern was U2 should put the IP
>>>>>>>>> in
>>>>>>>>> the URL but it wouldn¹t happen. This is fine. I agree that if we use
>>>>>>>>> the
>>>>>>>>> FQDN in the redirect, CDN2 will stream the content to U2 in native v6
>>>>>>>>> if
>>>>>>>>> the CDN2 supports v6.
>>>>>>>> 
>>>>>>>> So we should add a requirement along the lines of the one you
>>>>>>>> discussed
>>>>>>>> earlier with Dan:
>>>>>>>> 
>>>>>>>>> I would propose adding a general requirement to the document stating
>>>>>>>>> "any
>>>>>>>>> URIs returned to User Agents MUST NOT contain IP address literals in
>>>>>>>>> the
>>>>>>>>> <authority> component of the URI" or similar text.
>>>>>>>> 
>>>>>>>> Right?
>>>>>>>> 
>>>>>>>> Francois
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Yiu
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> U2 is behind NAT64 so CDN1 will see an IPv4 address for U2. That is
>>>>>>>>>> not
>>>>>>>>>> the issue. The issue is that NAT64 relies on the NAT64 device
>>>>>>>>>> synthesising
>>>>>>>>>> AAAA DNS responses as U2 only speaks DNSv6. But if U2 gets an v4
>>>>>>>>>> address
>>>>>>>>>> literal in the Content-Location header of a HTTP 302 it has no way
>>>>>>>>>> to
>>>>>>>>>> communicate with that v4 address as it has no native v4 capability
>>>>>>>>>> (or no
>>>>>>>>>> native v4 routing).
>>>>>>>>>> 
>>>>>>>>>> Using a FQDN (and avoiding v4 address literals) in the
>>>>>>>>>> Content-Location
>>>>>>>>>> header would avoid the issue as you first suggested.
>>>>>>>>>> 
>>>>>>>>>> Ben
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> CDNi mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Francois Le Faucheur
>>>>>>>> Distinguished Engineer
>>>>>>>> Corporate Development
>>>>>>>> [email-masked]
>>>>>>>> Phone: +33 49 723 2619
>>>>>>>> Mobile: +33 6 19 98 50 90
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Cisco Systems France
>>>>>>>> Greenside
>>>>>>>> 400 Ave de Roumanille
>>>>>>>> 06410 Sophia Antipolis
>>>>>>>> France
>>>>>>>> Cisco.com
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Think before you print.
>>>>>>>> 
>>>>>>>> This email may contain confidential and privileged material for the
>>>>>>>> sole use of the intended recipient. Any review, use, distribution or
>>>>>>>> disclosure by others is strictly prohibited. If you are not the
>>>>>>>> intended
>>>>>>>> recipient (or authorized to receive for the recipient), please contact
>>>>>>>> the sender by reply email and delete all copies of this message.
>>>>>>>> 
>>>>>>>> Cisco Systems France, Société à responsabiité limitée, Rue Camille
>>>>>>>> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
>>>>>>>> Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre,
>>>>>>>> Directeur
>>>>>>>> de la publication: Jean-Luc Michel Givone.
>>>>>>>> 
>>>>>>>> For corporate legal information go to:
>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> CDNi mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> CDNi mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> Francois Le Faucheur
>> Distinguished Engineer
>> Corporate Development
>> [email-masked]
>> Phone: +33 49 723 2619
>> Mobile: +33 6 19 98 50 90
>> 
>> 
>> 
>> Cisco Systems France
>> Greenside
>> 400 Ave de Roumanille
>> 06410 Sophia Antipolis
>> France
>> Cisco.com
>> 
>> 
>> 
>> 
>> Think before you print.
>> 
>> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
>> 
>> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
>> 
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> 
>> 
> 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: David R Oran <[email-masked]>
Date: Fri, 25 Mar 2011 11:07:10 -0400

> I suspect this can be improved, so suggestions are welcome.
The above is actually quite good, but I could not resist taking up the pen. If it's not too late to bother, see if folks like the wording below better:

"CDNI by its nature communicates uniform resource identifiers (URI's) it has received from one CDN element to other CDN elements in the interconnected CDNs. For CDNI to operate correctly, such references, known as "third party", must resolve to the same resource no matter which CDN element tries to de-reference it. Some URI forms are known to violate this invariant under various conditions. These include, for example, URIs containing RFC1918 addresses and URIs with DNS names that have been subjected to "split DNS" processing (where DNS accesses a different FQDN depending on where the query was originated). In particular, these considerations apply when the CDNI solution needs to construct and convey URIs for directing/redirecting a content request, as well as to situations where the CDNI solution needs to pass on a third party reference (e.g. to identify a User Agent) in order to allow another entity to take action based on the URI (e.g. make a superior request routing decision by attempting to derive location information from the third party reference). The CDNI system should avoid using such URI forms, and where this is not practical, take steps to mitigate the effects and check for errors. "

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 25 Mar 2011 18:25:13 +0100

Hi Dave,

Thanks. That looks good. Minor comments/questions below:

> "CDNI by its nature communicates uniform resource identifiers (URI's) it has received from one CDN element to other CDN elements in the interconnected CDNs.

or perhaps:
"CDNI by its nature involves communication of uniform resource identifiers (URI's) received from one CDN element to other CDN elements in the interconnected CDNs".

> For CDNI to operate correctly, such references, known as "third party", must resolve to the same resource no matter which CDN element tries to de-reference it. Some URI forms are known to violate this invariant under various conditions. These include, for example, URIs containing RFC1918 addresses and URIs with DNS names
> that have been subjected to "split DNS" processing (where DNS accesses a different FQDN depending on where the query was originated).

I pictured split DNS as possibly resolving differently the same FQDN. Is it accurate to say "where DNS accesses a different FQDN..".?

Francois

> In particular, these considerations apply when the CDNI solution needs to construct and convey URIs for directing/redirecting a content request, as well as to situations where the CDNI solution needs to pass on a third party reference (e.g. to identify a User Agent) in order to allow another entity to take action based on the URI (e.g. make a superior request routing decision by attempting to derive location information from the third party reference). The CDNI system should avoid using such URI forms, and where this is not practical, take steps to mitigate the effects and check for errors. "
> 
> 
>> Francois
>> 
>> 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: David R Oran <[email-masked]>
Date: Fri, 25 Mar 2011 14:16:01 -0400

> "CDNI by its nature involves communication of uniform resource identifiers (URI's) received from one CDN element to other CDN elements in the interconnected CDNs".
Sure. That's better.

> I pictured split DNS as possibly resolving differently the same FQDN. Is it accurate to say "where DNS accesses a different FQDN..".?
It's kind of slippery. Any load balancer "resolves differently the same FQDN", but that's ok because the resolutions are driven off the same state in one DNS zone. With split DNS, you are actually getting RRs from a *different* DNS entry, which is essentially saying it's a different FQDN. The reason is't a bit slippery is the subtle difference between "the FQDN" and "the character string that purports to be that FQDN".

I'm not sure what the best way to say this is, since some people won't understand how you can get a "different FQDN" when the input string is unchanged - but that's essentially how split DNS screws up the world. PErhaps we could say:

"been subjected to "split DNS" processing (where DNS accesses a different DNS entry for an FQDN depending on where the query was originated).

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 25 Mar 2011 19:21:01 +0100

> It's kind of slippery. Any load balancer "resolves differently the same FQDN", but that's ok because the resolutions are driven off the same state in one DNS zone. With split DNS, you are actually…

I see.

> "been subjected to "split DNS" processing (where DNS accesses a different DNS entry for an FQDN depending on where the query was originated).

that works much better for me.

Thanks

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.