Subject: Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-redirection-17: (with COMMENT)

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

Hi Ben C,

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 Alissa’s, Stephen's & your comments. That includes aligning the TLS text in the security considerations with that in cdni-logging-25 which is what was agreed in response to Alissa’s DISCUSS.

I believe I have incorporated all the other comments/edits you made into -18 and as far as I can tell there are no outstanding points/comments where you are expecting a response from me or my co-authors.

Let me know if that is not true and I have missed anything.

Thanks
Ben

> On 29 Mar 2016, at 00:19, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Hi Ben,
> 
>> On 28 Mar 2016, at 21:52, Ben Campbell <[email-masked]> wrote:
>> On 24 Mar 2016, at 10:02, Ben Niven-Jenkins wrote:
>>>> On 16 Mar 2016, at 02:21, Ben Campbell <[email-masked]> wrote:
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> I have a few comments and questions:
>>>> 
>>>> # Substantive: #
>>>> 
>>>> - 3, last paragraph: "Any operational
>>>> mechanisms this requires, e.g., private key distribution to
>>>> surrogates and request routers in dCDNs, are outside the scope of
>>>> this document.  Further mechanisms to notify User Agents of trusted
>>>> redirection are also outside the scope of this document."
>>>> 
>>>> Is it in scope _somewhere_? As it is, this seems like an excuse to avoid
>>>> HTTPS, which is not optimal.
>>> 
>>> I believe it is in scope of the LURK BoF.
>>> 
>>> I don’t understand your point about avoiding HTTPS. This is saying that once a User Agent connects to a surrogate or request router over HTTPS, that surrogate/request router better be able present the correct certificate, complete a TLS handshake, etc otherwise content delivery will fail. How a surrogate/request router manages to achieve that is outside of the scope of the redirection interface this document is specifying, similar to how a particular origin/web server/etc (without CDNI) manages to achieve that is outside of the scope of the HTTPS spec.
>> 
>> I'm not suggesting this draft has to offer solutions; that's why I asked if the work was in scope "somewhere". But it seems like key management, especially in an interoperable fashion, is kind of an "elephant in the room" for secure redirection.
> 
> Yes it is currently. Hopefully LURK will solve that in the future. Non-standardised techniques similar to some of the LURK proposals are deployed today, so the key management bit is solved IMO but are not documented in any kind of formal document AFAIK. 
> 
>>>> -4, first paragraph:
>>>> Was any thought given to using or supporting HTTP/2?
>>> 
>>> The authors gave it a bit of thought. It was not raised in the working group from what I remember.
>>> 
>>> I’m not sure HTTP/2 is particularly relevant to the specification. The CDNI RI spec is essentially a HTTP API for exchanging CDNI redirection requests/responses. Like any HTTP API it can feasibly be run over HTTP, HTTPS & HTTP/2 as the semantics of all three are the same.
>> 
>> Is saying it is based on HTTP 1.1 really accurate then? Or maybe it's just based on HTTP in general?
> 
> Good point. I’ve dropped the 1.1 in my working copy of -18.
> 
>>>> - 4.2, last paragraph (note)
>>>> This explicitly makes an IPv6 only CDN non-compliant. Is that the
>>>> intent?
>>> 
>>> I’m not sure how it does that, could you explain?
>>> 
>>> From my point of view the text is stating what formats for parsing IPv4 & IPv6 addresses implementations must support. It does not say that in order to use the CDNI redirection interface, one’s CDN must use IPv4.
>> 
>> Language of the form "MUST SUPPORT X encoded as Y" can be interpreted as "MUST support X and MUST support encoding as Y".
>> 
>> Suggestion:
>> OLD
>>  All implementations MUST support IPv4 addresses encoded as
>>  specified by the ’IPv4address’ rule in Section 3.2.2 of [RFC3986] and
>>  MUST support all IPv6 address formats specified in [RFC4291].
>> NEW
>>  All implementations that support IPv4 addresses MUST support
>>  the encoding specified by the ’IPv4address’ rule in
>>  Section 3.2.2 of [RFC3986]. Likewise, implementations that support
>>  IPv6 addresses MUST support all IPv6 address formats specified in [RFC4291].
>> END
> 
> Thanks. I’ve adopted your suggested text in my working copy of -18.
> 
>>>> - 4.4.1, table, entry for dns-only:
>>>> The description says "MUST include RTs". That doesn't seem to consider
>>>> error cases.
>>> 
>>> My intention was to state what someone must do under normal circumstances and I assumed that in the case of any error that prevented them from doing that, that they would return an appropriate error response instead.
>>> 
>>> I can change "If True then dCDN MUST only use DNS redirection and MUST include RTs to one or more surrogates in its RI response."
>>> 
>>> to
>>> 
>>> "If True then dCDN MUST only use DNS redirection and MUST include RTs to one or more surrogates in any successful RI response."
>>> 
>>> (or any other text you’d prefer) if that would alleviate your concern?
>> 
>> That works for me, thanks!
> 
> Done.
> 
>>>> -5.1, 2nd to last paragraph:
>>>> " In an environment where any such protection is required...," is a
>>>> pretty weak recommendation. Would you consider making the default
>>>> behavior secure? Or at least saying something to the effect of "Except in
>>>> networks where similar protections are provided by some other
>>>> means,…"?
>>> 
>>> 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?
>> 
>> I see Alissa has a DISCUSS position on this (and also on cdni-logging). I will defer to the outcome of that discussion.
> 
> Seems it has already been resolved but I missed the edits to the latest logging draft, so I’ve adopted those in my working copy of -18 which should hopefully clear this from both yourself & Alissa when I publish -18 (there’s a few more still to be agreed with Alissa & Stephen).
> 
>>>> -- third paragraph:
>>>> I wish the text wasn't so dismissive of attempts to anonymize some RI
>>>> request data. I agree doing so may reduce RI effectiveness in some cases.
>>>> But that needs to be balanced with privacy needs, and that balance may
>>>> not always land on the side of RI effectiveness. And  the inability to
>>>> correlate UAs between requests can be a feature in some circumstances.
>>> 
>>> I agree where the balance lands may be different depending on circumstances. If you can suggest specific edits/new text that comes across less dismissive, I’ll incorporate them.
>>> 
>> 
>> Suggestion:
>> OLD
>>  While it is technically possible to mask some information in the RI
>>  Request, such as the last bits of the UA IP address, it is important
>>  to note that this will reduce the effectivess of the RI in certain
>>  cases.  As an example, when the UA is behind a Carrier-grade NAT, and
>>  the RI is used to find an appropriate delivery node behind the same
>>  NAT, the full IP address might be necessary.  Another potential issue
>>  when using IP anonymization is that it is no longer possible to
>>  correlate an RI Request with a subsequent UA request.
>> NEW:
>>  While it is technically possible to mask some information in the RI
>>  Request, such as the last bits of the UA IP address, it is important
>>  to note that this will reduce the effectivess of the RI in certain
>>  cases. CDN deployments need to strike a balance between end-user
>>  privacy and the features impacted by such masking. This balance is
>>  likely to vary from one deployment to another.  As an example, when
>>  the UA is behind a Carrier-grade NAT, and the RI is used to find an
>>  appropriate delivery node behind the same NAT, the full IP address
>>  might be necessary.  Another potential issue when using IP
>>  anonymization is that it is no longer possible to correlate an
>>  RI Request with a subsequent UA request.
> 
> I’ve adopted your suggested text. Alissa has a comment on the language here and Stephen has a discuss on privacy concerns in general so I suspect this text might change some more before we’re finished with the document.
> 
>>>> # Editorial: #
>>>> 
>>>> - General:
>>>> There's quite a bit of repetition and redundant text, including redundant
>>>> normative text.
>>> 
>>> Do you think the repetition is harmful? I’m reluctant to rework the document unless really necessary.
>> 
>> I personally think such repetition has the potential to confuse the reader, or to make life harder for people who may update the draft in the future. But I recognize a lot of work has gone into getting people to agree to the current language, so I think it's your call.
> 
> I’ll probably need to give the document a full read through after making changes to address Stephen’s discuss so I’ll look out for obvious repetition then and have a go at reducing some of it.
> 
> Ben
> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 18 Apr 2016 12:58:03 -0500

Hi Ben N-J :-)

I notice in section 4 that you dropped the "1.1" from the mention of 
HTTP. But the reference to RFC 7230 is still 1.1 specific. You might 
consider also adding a reference for http/2.

I will defer to whatever is worked out with Stephen and Alissa for 5.1.

Otherwise, this seems to address all of my comments.

Thanks!

Ben.

On 16 Apr 2016, at 1:55, Ben Niven-Jenkins wrote:

> I’ve published a -18 that contains all the editorial/other edits 
> made in response to Alissa’s, Stephen's & your comments. That 
> includes aligning the TLS text in the security considerations with 
> that in cdni-logging-25 which is what was agreed in response to 
> Alissa’s DISCUSS.
>
> I believe I have incorporated all the other comments/edits you made 
> into -18 and as far as I can tell there are no outstanding 
> points/comments where you are expecting a response from me or my 
> co-authors.
>
>>>> I don’t understand your point about avoiding HTTPS. This is 
>>>> saying that once a User Agent connects to a surrogate or request 
>>>> router over HTTPS, that surrogate/request router better be able 
>>>> present the correct certificate, complete a TLS handshake, etc 
>>>> otherwise content delivery will fail. How a surrogate/request 
>>>> router manages to achieve that is outside of the scope of the 
>>>> redirection interface this document is specifying, similar to how a 
>>>> particular origin/web server/etc (without CDNI) manages to achieve 
>>>> that is outside of the scope of the HTTPS spec.
>>>
>>> I'm not suggesting this draft has to offer solutions; that's why I 
>>> asked if the work was in scope "somewhere". But it seems like key 
>>> management, especially in an interoperable fashion, is kind of an 
>>> "elephant in the room" for secure redirection.
>>
>> Yes it is currently. Hopefully LURK will solve that in the future. 
>> Non-standardised techniques similar to some of the LURK proposals are 
>> deployed today, so the key management bit is solved IMO but are not 
>> documented in any kind of formal document AFAIK.
>>
>>>>> -4, first paragraph:
>>>> I’m not sure HTTP/2 is particularly relevant to the 
>>>> specification. The CDNI RI spec is essentially a HTTP API for 
>>>> exchanging CDNI redirection requests/responses. Like any HTTP API 
>>>> it can feasibly be run over HTTP, HTTPS & HTTP/2 as the semantics 
>>>> of all three are the same.
>>>
>>>> From my point of view the text is stating what formats for parsing 
>>>> IPv4 & IPv6 addresses implementations must support. It does not say 
>>>> that in order to use the CDNI redirection interface, one’s CDN 
>>>> must use IPv4.
>>>
>>> Language of the form "MUST SUPPORT X encoded as Y" can be 
>>> interpreted as "MUST support X and MUST support encoding as Y".
>>>
>>> Suggestion:
>>> OLD
>>>> My intention was to state what someone must do under normal 
>>>> circumstances and I assumed that in the case of any error that 
>>>> prevented them from doing that, that they would return an 
>>>> appropriate error response instead.
>>>>
>>>> I can change "If True then dCDN MUST only use DNS redirection and 
>>>> MUST include RTs to one or more surrogates in its RI response."
>>>>
>>>> to
>>>>
>>>> "If True then dCDN MUST only use DNS redirection and MUST include 
>>>> RTs to one or more surrogates in any successful RI response."
>>>>
>>>> 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?
>>>
>>> I see Alissa has a DISCUSS position on this (and also on 
>>> cdni-logging). I will defer to the outcome of that discussion.
>>
>> Seems it has already been resolved but I missed the edits to the 
>> latest logging draft, so I’ve adopted those in my working copy of 
>> -18 which should hopefully clear this from both yourself & Alissa 
>> when I publish -18 (there’s a few more still to be agreed with 
>> Alissa & Stephen).
>>
>>>>> -- third paragraph:
>>>> I agree where the balance lands may be different depending on 
>>>> circumstances. If you can suggest specific edits/new text that 
>>>> comes across less dismissive, I’ll incorporate them.
>>>>
>>>
>>> Suggestion:
>>> OLD
>> I’ve adopted your suggested text. Alissa has a comment on the 
>> language here and Stephen has a discuss on privacy concerns in 
>> general so I suspect this text might change some more before we’re 
>> finished with the document.
>>
>>>>> # Editorial: #
>>>>>
>>>>> - General:
>>> I personally think such repetition has the potential to confuse the 
>>> reader, or to make life harder for people who may update the draft 
>>> in the future. But I recognize a lot of work has gone into getting 
>>> people to agree to the current language, so I think it's your call.
>>
>> I’ll probably need to give the document a full read through after 
>> making changes to address Stephen’s discuss so I’ll look out for 
>> obvious repetition then and have a go at reducing some of it.
>>
>> Ben
>>
>>