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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 15 Mar 2016 19:21:19 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-cdni-redirection-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/

----------------------------------------------------------------------
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.

-4, first paragraph:
Was any thought given to using or supporting HTTP/2?

-- step 1 after figure 1:
I am I correct to infer an assumption that CDN A acts as the UAs DNS
server? Is that assumption documented somewhere?

- 4.2, last paragraph (note)
This explicitly makes an IPv6 only CDN non-compliant. Is that the
intent?

- 4.4.1, table, entry for dns-only:
The description says "MUST include RTs". That doesn't seem to consider
error cases. 

- 4.8, 3rd and 4th paragraph:
I'm curious why they SHOULDs are not MUSTs. Are there times it might be
reasonable to do something different; maybe even choosing not to send an
error at all? I wonder if these should be of the form of "MUST send an
error which SHOULD be XXX"

-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,..."?

-5.2, First paragraph:
I have trouble imagining situations where information passed over the RI
might not be sensitive.
-- 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. 

# Editorial: #

- General:
There's quite a bit of repetition and redundant text, including redundant
normative text.

- abstract: 
s/"The Request Routing Interface..."/ "The Content Delivery Network
Interface (CDNI) Request Routing Interface..."
s/"comprises of"/"comprises"

- 4, 2nd paragraph: "The same HTTP interface is used for both DNS and
HTTP redirection of
User Agent requests,..."
>From the rest of the sentence, I assume this means the RI uses the same
interface to communicate information about DNS and HTTP redirects—but the
first part sounds like it is saying that the actual redirection (i.e.
interacting with the UA) occurs over the same interface.

-- 4th paragraph:
s/"try and"/"try to"

- 4.1, 2nd to last paragraph: "... signaled the HTTP response body
      of the RI response ..."
Missing word? (perhaps "... signaled in the HTTP response body ..."

-4.2, paragraph 4:
This paragraph is redundant to section 4.8.

-4.5.1, last paragraph before example: "For example, it MAY only
   send the contents of the first occurrence of the HTTP Headers
   instead."
s/MAY/might.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 24 Mar 2016 15:02:09 +0000

Hi Ben,
(Francois, Kevin, there is a question from Ben below that I think needs your input as WG chairs)

> On 16 Mar 2016, at 02:21, Ben Campbell <[email-masked]> wrote:

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.

> 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.  

> server? Is that assumption documented somewhere?

No, CDN A does not act as the UA’s caching DNS server. The text/diagram is a bit simplified to be able to show the main idea and collapse the DNS & HTTP cases for brevity as they are largely the same.

When the document says:

"The User Agent sends its (DNS or HTTP) request to CDN A.”

what it really means is:

“If HTTP redirection is being used between the UA & CDN A, the User Agent sends its HTTP request to CDN A. If DNS redirection is being used between the UA & CDN A, the User Agent sends a DNS request to its configured DNS resolver, normal DNS caching infrastructure interactions occur and if a suitable response is not already cached, the last DNS resolver in the chain will send a DNS request to CDN A."

If you think including the above text (or a modified version you’d like to suggest) would help the clarity of the document I’m happy to add it?

> This explicitly makes an IPv6 only CDN non-compliant. Is that the

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.

> The description says "MUST include RTs". That doesn't seem to consider

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?

> error which SHOULD be XXX”

You’re right I think we were a bit lax here. The only thing I was thinking was maybe someone would want to return a different error code for some reason we haven’t thought of.

I prefer your suggestion of "MUST send which SHOULD be” so I’ve changed the two paragraphs in my working copy of -18 to be:
"the dCDN MUST send an RI error response which SHOULD include an error code of XXX” (with XXX replaced by the appropriate error code).

> 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 have trouble imagining situations where information passed over the RI

Fair point. I have changed it to now read

“Information passed over the RI ought to be considered personal and sensitive."

(I wanted to say “should be considered” but that would be ambiguous about whether it is really should or SHOULD so I settled on “ought to be” but if you can think of a better way to phrase it I’m happy to use it)

> 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. 

> There's quite a bit of repetition and redundant text, including redundant

Do you think the repetition is harmful? I’m reluctant to rework the document unless really necessary. 

> s/"comprises of"/“comprises"

Done.

> interacting with the UA) occurs over the same interface.

I reworded to make the distinction clearer (hopefully), this is what I have now:

"The RI between the uCDN and dCDN uses the same HTTP interface to encapsulate the attributes of both DNS and HTTP requests received from User Agents…"

> s/"try and"/"try to”

Done

> Missing word? (perhaps "... signaled in the HTTP response body …"

Done

> This paragraph is redundant to section 4.8.

I’ve removed this paragraph from my working copy of -18

>   send the contents of the first occurrence of the HTTP Headers

Done

Ben

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Mar 2016 15:52:58 -0500

Hi, Thanks for the response. Comments inline. I removed sections that do 
not seem to need further comment.

Ben.

On 24 Mar 2016, at 10:02, Ben Niven-Jenkins wrote:

> 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.

> 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?

> No, CDN A does not act as the UA’s caching DNS server. The 
> text/diagram is a bit simplified to be able to show the main idea and 
> collapse the DNS & HTTP cases for brevity as they are largely the 
> same.
>
> When the document says:
>
> “If HTTP redirection is being used between the UA & CDN A, the User 
> Agent sends its HTTP request to CDN A. If DNS redirection is being 
> used between the UA & CDN A, the User Agent sends a DNS request to its 
> configured DNS resolver, normal DNS caching infrastructure 
> interactions occur and if a suitable response is not already cached, 
> the last DNS resolver in the chain will send a DNS request to CDN A."
>
> If you think including the above text (or a modified version you’d 
> like to suggest) would help the clarity of the document I’m happy to 
> add it?
>

I probably misstated my question. I understand from your response that 
CDN A hosts the authoritative DNS server for domains it services. That's 
already covered in the definition of DNS based redirection, so that's 
all good.

> 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

> 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."
>

That works for me, thanks!

> You’re right I think we were a bit lax here. The only thing I was 
> thinking was maybe someone would want to return a different error code 
> for some reason we haven’t thought of.
>
> I prefer your suggestion of "MUST send which SHOULD be” so I’ve 
> changed the two paragraphs in my working copy of -18 to be:
> "the dCDN MUST send an RI error response which SHOULD include an error 
> code of XXX” (with XXX replaced by the appropriate error code).

That helps, thanks!

> 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.

> (I wanted to say “should be considered” but that would be 
> ambiguous about whether it is really should or SHOULD so I settled on 
> “ought to be” but if you can think of a better way to phrase it 
> I’m happy to use it)

Modulo the ongoing discussion about lower-case usage of 2119 keywords, 
I'm fine with that :-)

> 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.

> 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.

[...]

> "The RI between the uCDN and dCDN uses the same HTTP interface to 
> encapsulate the attributes of both DNS and HTTP requests received from 
> User Agents…"

That helps, thanks.

[...]

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 29 Mar 2016 00:19:51 +0100

Hi Ben,

> On 28 Mar 2016, at 21:52, Ben Campbell <[email-masked]> wrote:
> 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. 

> 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.

> 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
>   specified by the ’IPv4address’ rule in Section 3.2.2 of [RFC3986] and
>   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.

Done.

> 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).

>   cases.  As an example, when the UA is behind a Carrier-grade NAT, and
>   NAT, the full IP address might be necessary.  Another potential issue

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.

> 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