Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS)

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 16 Apr 2016 07:52:02 +0100

Hi Alissa,

I wanted to give you an update on where we are:

I’ve published a -18 that contains all the editorial/other edits made in response to Ben Campbell’s, Stephen's & your comments. That includes aligning the TLS text in the security considerations with that in cdni-logging-25.

We have also started a discussion on privacy with some folks Stephen recommended and will update the document based on that discussion, which may improve the text wrt some of the comments you have made.

As far as I can tell there are no outstanding points in your DISCUSS where you are expecting a response from me or my co-authors, although I assume you’ll want to re-read the new draft once its published based on the edits wrt privacy we will make before clearing your DISCUSS?

Thanks
Ben

> On 24 Mar 2016, at 15:05, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Hi Alissa,
> (Francois, Kevin, there is a question from Alissa below that I think needs your input as WG chairs)
> 
>> On 16 Mar 2016, at 23:23, Alissa Cooper <[email-masked]> wrote:
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> (1)
>> There is some ambiguity in the document about whether the uCDN passes the
>> IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that for
>> DNS redirection, the uCDN passes "IP address or prefix" of the UA, but
>> then in the definition of resolver-ip specifies it only as the IP address
>> of the UA.
> 
> resolver-ip contains “The IP address of the UA’s DNS resolver."
> 
> c-subnet contains the "The IP address (or prefix) of the UA in CIDR format."
> 
> The idea is resolver-ip contains the IP address of the DNS resolver making the DNS request to the uCDN. c-subnet contains (if present) the address/prefix carried by draft-ietf-dnsop-edns-client-subnet.
> 
>> Then in Sec 4.5.1 for HTTP redirection the equivalent field is
>> specified as the IP address of the UA and the possibility of sending only
>> a prefix is not mentioned.
> 
> That is because with HTTP the UA connects directly to the uCDN and the uCDN can see the UA’s IP address.
> 
>> Then 5.2 has the para that begins "While it is
>> technically possible to mask some information in the RI Request, such as
>> the last bits of the UA IP address ..." which makes it seem like prefixes
>> really shouldn't be sent.
> 
> What we have provided is the ability for the CDNI Redirection Interface to encode the properties of the source (DNS or HTTP) requests so that uCDNs & dCDNs can make the best dCDN & surrogate selection decisions that they can. We’re not suggesting or mandating any additional IP address masking behaviour than that provided (or not provided) by the source protocol. This may be the source of the confusion - we’re not saying “you should mask the IP address behind a prefix and this is how to do it” and then being inconsistent about applying it to DNS vs HTTP, we’re saying “here’s how to encapsulate a DNS or HTTP request into our protocol”.
> 
>> 
>> I think the document needs some consistency and clarity here about
>> whether prefixes are expected to be used for either redirection method.
> 
> Does the above explanation change this view? Or change the text you would like to see that provides that clarity?
> 
>> It's also not obvious to me why the document shouldn't recommend to uCDNs
>> that if they are polling multiple candidate dCDNs as described in Sec
>> 5.2, they should use only a prefix for such requests. The arguments given
>> against this seem pretty thin -- isn't preventing correlation of multiple
>> requests to a single UA a good thing, especially when it's being done by
>> a bunch of dCDNs? And I don't understand the CGN example -- isn't the
>> root of the problem here that topologically dispersed UAs are sharing the
>> same public-facing IP address, in which case the dCDN may have the same
>> problem when passed a full IP address as it does a prefix? 
> 
> We describe how to encapsulate DNS & HTTP requests in the RI protocol and we discuss that in some circumstances it may provide information to a dCDN that they would not otherwise have got and that masking IP addresses also has downsides.
> 
> We do not provide any privacy enhancing normative behaviour and we do not make a value judgement on whether any possible reduction in privacy is more important than the downsides of providing that reduction in privacy.
> 
> The specific example of CGN may not be the best example for us to have used. The general point is that dCDNs perform surrogate selection using UA IP address (or the closest proxy they can get, e.g. the UA’s DNS resolver’s IP address) and that masking the UA IP address therefore means dCDNs may make less optimum decisions and that is a downside.
> 
> Maybe we’d be better just saying that rather than trying to provide specific scenarios that say that by inference?
> 
>> 
>> (2)
>> Ben noted the weakness of the recommendation in 5.1 regarding TLS. I see
>> that the language here is the same as it is in
>> draft-ietf-cdni-logging-22. But I thought the agreement on that document
>> was MUST use TLS, full stop. So there is ambiguity in both documents I
>> think. "In an environment where ..." and "When TLS is used ..." seem
>> inconsistent with "TLS MUST be used ...." I'm happy to clear on this if
>> I'm missing something from the previous discussion, which I think
>> happened when I was on leave and resulted from one of Stephen's ballots.
> 
> What I replied to Ben…"There has been quite a bit of discussion in the CDNI WG around this wording and the WG decided to align the wording it used across all its documents. The first document to progress to IESG was draft-ietf-cdni-logging and the other CDNI drafts (including the redirection one we are discussing) use the same wording as draft-ietf-cdni-logging.
> 
> I’m happy to continue to align the wording in this document with that in draft-ietf-cdni-logging, but I would suggest we avoid repeating the same discussion that is happening around draft-ietf-cdni-logging here.
> 
> Francois/Kevin - Can you help here? Has the discussion around this text for draft-ietf-cdni-logging concluded yet?"
> 
> Ben
>