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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 16 Mar 2016 16:23:03 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-cdni-redirection-17: Discuss

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/

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

I think the document needs some consistency and clarity here about
whether prefixes are expected to be used for either redirection method.
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? 

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

---

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

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

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

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

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

> 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

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 24 Mar 2016 17:19:30 +0000

> Francois/Kevin - Can you help here? Has the discussion around this text
> for draft-ietf-cdni-logging concluded yet?"

Yes!  (Woohoo!)  All DISCUSS's on Logging have been cleared, and Triggers has updated it's text to match Logging.  We can go ahead and update Redirection to grab the same text.  thanx!

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Thursday, March 24, 2016 11:06 AM
> To: Alissa Cooper
> Cc: The IESG; [email-masked]; [email-masked]; cdni-
> [email-masked]
> Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-
> redirection-17: (with DISCUSS)
> 
> Hi Alissa,
> 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.
> 
> 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”.
> 
> >
> 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)
> 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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 24 Mar 2016 17:34:50 +0000

Kevin,

> Yes!  (Woohoo!)  All DISCUSS's on Logging have been cleared, and Triggers has updated it's text to match Logging.  We can go ahead and update Redirection to grab the same text.  thanx!

From what I can tell redirection-17 has the same text as logging-22 which has different text to triggers-12. Which text should I use in redirection-18?

Thanks
Ben

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 24 Mar 2016 17:47:30 +0000

Hi Ben,

  I'm looking at the text in 7.1 of logging-23 and 8.1 of triggers-12.  They are worded a little differently, but I think the gist of it is:

   A CI/T implementation MUST support TLS transport for HTTP (https) as
   per [RFC2818] and [RFC7230].

   [triggers has a MUST statement here about "authentication of the remote end"; logging's is below]

   The use of TLS for transport of the CI/T interface allows:

   o  [dCDN and uCDN to authenticate each other].

   And, once they have mutually authenticated each other, it allows:

   o  The dCDN and the uCDN to authorize each other [for interface specific purpose].

   o  [interface specific stuff] to be transmitted with
      confidentiality.

   o  Protection of the integrity of [interface specific stuff].

   When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
   followed.

   [logging has a MUST statement here about "authentication of the remote end"]

thanx.

--  Kevin J. Ma

> Sent: Thursday, March 24, 2016 1:35 PM
> To: Kevin Ma J
> Cc: Alissa Cooper; The IESG; [email-masked]; draft-ietf-cdni-
> [email-masked]; [email-masked]
> > Yes!  (Woohoo!)  All DISCUSS's on Logging have been cleared, and
> Triggers has updated it's text to match Logging.  We can go ahead and
> update Redirection to grab the same text.  thanx!
> 
> From what I can tell redirection-17 has the same text as logging-22 which
> has different text to triggers-12. Which text should I use in redirection-
> 18?
> 
> Thanks
> Ben
> 
> >
> >> (Francois, Kevin, there is a question from Alissa below that I think
> needs
> >> your input as WG chairs)
> >>
> >> Does the above explanation change this view? Or change the text you
> would
> >> like to see that provides that clarity?
> >>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 24 Mar 2016 18:00:05 +0000

OK, i'd missed -23 of logging. I will align the text in redirection-18 with logging-23. Ben

> On 24 Mar 2016, at 17:47, Kevin Ma J <[email-masked]> wrote:
> 
> Hi Ben,
>