Subject: [CDNi] Comments re Re: I-D Action: draft-ni-cdni-criteria-metadata-extension-00.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 19 Jul 2012 09:01:10 +0000

Hello Wei, Yana, Yunfei,

The I-D says:
"
The object includes the following fields:
   O country - a string containing the country code for the region.
   O bgpAs - a number containing the BGP AS identifier of the region.
   O subnet - a string containing a dotted decimal IP address and
   subnet mask, here the IP address is the source IP address in IP
   layer.
   O msdnPrefix - a few digits in MSISDN specifying user's home area
   information in mobile network. MSISDN should be extracted from HTTP
   Header by the surrogate of downstream CDN.
   O subnet2 - a string containing a dotted decimal IP address
   extracted from the HTTP x-forwarded-for header and the corresponding
   subnet mask, which specifies the real IP address of mobile devices
   assigned by mobile core network. The IP address should be extracted
   from HTTP Header by the surrogate of downstream CDN.
"

The Location object of cjlmw-cdni-metadata is described as:
"
   | Location    | Geographic or network location identified by     		   |
   |                  | country code, BGP AS number, or subnet to which  	   |
   |                  | content may (or may not) be delivered. 
"
Can you confirm that your first three criteria ("Country", "BGP AS" and "Subnet") are addressed as you see needed?

Regarding the last 2 criteria, I would like to encourage you to work (ideally before Vancouver) with the authors of the current CDNI Metadata proposals (e.g. cjlmw-cdni-metadata and ma-cdni-metadata) to discuss whether/how those could be integrated in the current metadata proposals. On that, my personal input is:
	* I can see the rationale for extending the geoblocking based on the IP address allocated based on current location (ie your "Subnet2").
	* I am somewhat skeptical on the requirements to control distribution based on ranges of the Mobile number (ie your "msdnPrefix"), particularly considering number portability. I would be interested in hearing other opinions on that.

Regardless of which document the discussion of "subnet2" ends up in the future, I suggest an editor's note be incorporate to remind us to check the status of "draft-petersson-forwarded-for" (unless someone can update us on that) to decide whether we ought to extend the description to cover the proposed "Forwarded" header, in addition to the X-Forwarded-For header.

Cheers

Francois

On 9 Jul 2012, at 19:41, <[email-masked]>
 <[email-masked]> wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : CDNI Delivery Criteria Metadata Extension for Mobile Network
> 	Author(s)       : Wei Ni
>                          Yana Bi
>                          Yunfei Zhang
> 	Filename        : draft-ni-cdni-criteria-metadata-extension-00.txt
> 	Pages           : 11
> 	Date            : 2012-07-09
> 
> Abstract:
>   In CDNI deployment, the downstream  CDN may probably delivers
>   content to mobile devices, which is served by cellular networks
>   (e.g., 2G, 3G). The purpose of this document is to provide some
>   complement to the delivery criteria in current Metadata Interface
>   with a more precise criteria model, which is in consideration of
>   content delivery service to mobile devices.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ni-cdni-criteria-metadata-extension
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ni-cdni-criteria-metadata-extension-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 19 Jul 2012 09:19:33 +0000

On 19 Jul 2012, at 11:01, Francois Le Faucheur (flefauch) wrote:

Here is some update from the horse's mouth:

On 19 Jul 2012, at 11:12, Andreas Petersson wrote:

Hi,

The name has changed to draft-ietf-appsawg-http-forwarded, version -06
is the latest version. It is currently in IETF Last Call.
See http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/

Regards,
Andreas Petersson

Francois

Cheers

Francois

On 9 Jul 2012, at 19:41, <[email-masked]<mailto:[email-masked]>>
<[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

[email-masked]<mailto:[email-masked]>

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 23 Jul 2012 22:06:48 +0100

Francois, Wei, Yana, Yunfei,

My thoughts inline.

> 	* I can see the rationale for extending the geoblocking based on the IP address allocated based on current location (ie your "Subnet2").

As I understand it the situation/use case described in draft-ni-cdni-criteria-metadata-extension is this:

- The client is sat behind some kind of gateway device (WAP gateway, CG-NAT, etc.) so that the CDN's request router/surrogate does not see the client's IP address but instead it sees the IP address of the gateway device.
- Geo-blocking must continue to work in this scenario and the specific worry is that the CDN may block access based on the gateway's IP address where it would have allowed access had it seen the client's actual IP address.

My first comment is that this scenario/use case exists today and the solution taken is to ensure the gateway's IP address is included in the allowed geo-blocking policy. So the scenario/use case by itself doesn't raise any specific additional requirements on CDNI.

However, in some scenarios it may be useful for the CDN request router/surrogate to factor in the client's actual IP address, e.g. because the gateway is aggregating for multiple network regions/provinces and you'd like the request router to be able to do a finer grained cache selection, and in some cases (e.g. HTTP redirection) the X-Forwarded-For can expose that information to the CDN's request router.

For that sort of scenario I'd suggest that we don't try to overload geo-blocking by having another category of Location which means "a list of IP addresses to extract/compare from the X-FF header". Instead one ensures that the gateway's IP address is allowed by the normal geo-blocking policy (as today) and we have a CDNI Metadata property/flag that indicates a dCDN should use the client IP address from the X-FF header for certain (defined) decisions.

However, the X-FF header is not a secure header and can be subject to modification by intermediaries and therefore blindly trusting it is a security risk for CDNs. So a dCDN should only use the X-FF header when it knows (somehow, probably out of band) that that particular gateway is to be trusted.

Additionally, it would seem that the only entity to be 'harmed' by not using the X-FF header is the dCDN because they dCDN may make a less efficient surrogate selection. 

That leads me to think that use of X-FF from trusted gateways is primarily an implementation optimisation for the dCDN. We could add a property to explicitly allow/disallow the dCDN to use X-FF to cover cases of a paranoid uCDN that doesn't trust the dCDN's choice of trusted gateways.

Ben

> [email-masked]