Subject: Re: [CDNi] Review comments on draft-ietf-cdni-redirection-04.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Dec 2014 11:24:23 +0000

Hi Francois,

I've incorporated the editorial comments below into my working copy of -06. I'll respond to the TLS comments separately later.

Ben
 
On 28 Nov 2014, at 10:59, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> All,
> 
> (as an individual)
> 
> My suggestions/comments below.
> 
> Francois
> 
> 
> ===========================================================
> 
> *** Figure 1:
> OLD:
> “
> with body containing attributes
> “
> NEW:
> “
> with body containing RT attributes
> “
> 
> 
> 
> *** section 4:
> OLD:
> “
> 3.  The Request Routing System of CDN B processes the request
> “
> NEW:
> “
> 3.  The Request Routing System of CDN B processes the RI request
> "
> 
> 
> *** section 4.2:
> OLD:
> “
> o  Requests or responses containing duplicate keys or containing keys
>      that are not all lowercase are considered syntactically invalid.
> “
> NEW:
> “
> o  Requests or responses containing duplicate keys or containing keys
>      that are not all lowercase MUST be considered syntactically invalid.
> “
> 
> 
> *** section 4.2:
> OLD:
> “
> the dCDN it is making the request to then
> “
> NEW:
> “
> the dCDN it is making the request to, then
> "
> 
> 
> 
> 
> *** section 4.2:
> OLD:
> “
> a transit CDN appends
> “
> NEW:
> “
> a transit CDN MUST append
> “
> 
> 
> *** section 4.3:
> OLD:
> “
> RI requests SHOULD use
> “
> NEW
> "
> RI requests MUST use
> “
> 
> 
> *** section 4.3:
> OLD:
> “
> RI responses SHOULD use
> “
> NEW
> "
> RI responses MUST use
> “
> 
> 
> *** section 4.4
> OLD:
> “
> provide more detailed descriptions
> “
> NEW:
> “
> provide detailed descriptions
> “
> 
> 
> *** section 4.4
> “DNS response code” 
> Please add a reference where these codes are specified.
> 
> 
> 
> *** section 4.5
> OLD:
> “
> provide more detailed descriptions
> “
> NEW:
> “
> provide detailed descriptions
> “
> 
> 
> *** section 4.5.1
> OLD:
> “
> the User Agent's DNS query/request
> “
> NEW:
> “
> the User Agent's HTTP request
> “
> 
> 
> *** section 4.7
> OLD:
> “
> From a uCDN perspective, there are two types of errors that can be
>   the result of the transmission of an RI request to a dCDN: An HTTP
>   protocol error signaled via an HTTP status code, indicating a problem
>   with the reception or parsing of the RI request or the generation of
>   the RI response by the dCDN, and a RI-level error specified in an RI
>   response message.
> “
> NEW:
> “
> From a uCDN perspective, there are two types of errors that can be
>   the result of the transmission of an RI request to a dCDN: 
> 	(i ) An HTTP protocol error signaled via an HTTP status code, indicating a problem
>   with the reception or parsing of the RI request or the generation of
>   the RI response by the dCDN, and 
> 	(ii) a RI-level error specified in an RI response message.
> “
> 
> 
> *** section 4.7
> “
> To aid with diagnosing the cause of errors, RI responses may include an
>   error dictionary to provide additional information to the uCDN as to
>   the reason/cause of the error.
> “
> should the “may” be a “MAY” , or perhaps even a “SHOULD”?
> 
> 
> *** section 5:
> This section should mandate support for TLS and discuss when it should be used.
> This section should mandate support for some cypher suite.
> This is common to all CDNI interfaces, so align with cdni-logging (and cdni-metadata as discussed in Honolulu).
> 
> 
> 
>> On 25 Oct 2014, at 10:18, Ben Niven-Jenkins <[email-masked]> wrote:
>> 
>> Colleagues,
>> 
>> This version is identical to -03 with the exception that we removed the editors' note on adding a section for FCI capabilities as it is no longer required as per the plan for FCI outlined by Francois & Kevin.
>> 
>> Ben
>> 
>> On 25 Oct 2014, at 09:14, [email-masked] wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.
>>> 
>>>      Title           : Request Routing Redirection Interface for CDN Interconnection
>>>      Authors         : Ben Niven-Jenkins
>>>                        Ray van Brandenburg
>>> 	Filename        : draft-ietf-cdni-redirection-04.txt
>>> 	Pages           : 29
>>> 	Date            : 2014-10-25
>>> 
>>> Abstract:
>>> The Request Routing Interface comprises of (1) the asynchronous
>>> advertisement of footprint and capabilities by a downstream CDN that
>>> allows a upstream CDN to decide whether to redirect particular user
>>> requests to that downstream CDN; and (2) the synchronous operation of
>>> an upstream CDN requesting whether a downstream CDN is prepared to
>>> accept a user request and of a downstream CDN responding with how to
>>> actually redirect the user request.  This document describes an
>>> interface for the latter part, i.e. the CDNI Request Routing
>>> Redirection interface.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-cdni-redirection-04
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-04
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> CDNi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Dec 2014 11:25:34 +0000

Francois, Kevin & Colleagues,

As part of reviewing draft-ietf-cdni-redirection it has been suggested to mandate the use of TLS and to mandate support for some cipher suite.

I am against such a change.

The RI interface document lays out in the security considerations section the threats and then recommends (SHOULD) secure and authenticated communication.

I have changed that to a MUST in the latest draft which now reads
   In order to prevent passive interception of RI messages the RI
   communications channel MUST be suitably secured (e.g. use of TLS).

   In order to reduce the risk of information leakage to unauthorized
   parties, RI clients and servers MUST use suitable authentication
   prior to trusting the contents of RI messages.

which I believe to be sufficient.

I am against mandating TLS as it is not the only mechanism available for securing the redirection interface, e.g. CDNs may use IPSec tunnels and run the RI over them. The document already suggests TLS by example and defines that the RI MUST run over a  suitably secured & authenticated channel.

Mandating TLS adds nothing extra to the specification except inflexibility for deployers.

Likewise recommending a particular cipher suite seems problematic as we are not security experts and the recommended suite may change over time forcing a need to update the RFC just to update the advice on cipher suites. Better to have the deployer follow the current best practice for the secure channel they choose to deploy over IMO.

If the consensus of the working group is that we should mandate a specific secure channel and/or a specific cipher suite, I'm OK to be declared in the rough and make the necessary editorial changes. But I do believe we're better off not going there and leaving it to deployers to decide what is most appropriate for their environment.

Ben