Skip to main content

Content Delivery Network Interconnection (CDNI) Request Routing Extensions
draft-ietf-cdni-request-routing-extensions-08

Yes

(Barry Leiba)

No Objection

(Alexey Melnikov)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 07 and is now closed.

Roman Danyliw
(was Discuss) No Objection
Comment (2019-11-21) Sent for earlier
Thank you for addressing my DISCUSSes and COMMENTs.
Warren Kumari
No Objection
Comment (2019-10-15 for -07) Sent
Thank you for writing this, also thank you for addressing the OpsDir Review comments. Also thank you to wangzitao@huawei.com for the review.
Éric Vyncke
No Objection
Comment (2019-10-14 for -07) Sent
Thank you for the work put into this document. I have a couple of comments and nits.

Regards,

-éric

== COMMENTS ==

One generic suggestion (no need to act on a COMMENT): add the definition of "router" in this document as it is not the typical IP-layer router as in most IETF documents.

-- Section 2.3 --
It is unclear to me whether the 3xx redirection (cfr last example) can switch from HTTP to HTTPS or vice-versa? Should the 'httptarget' include the scheme/protocol to be used ? In any case, the text should be clear whether the scheme is kept between original request and the scheme in the redirected location. Or is it specify in the OpenCache spec ?


== NITS ==

-- Abstract --
Please expand FCI at first use.

-- Requirements language --
Unusual place in the document. It will be fixed by the RFC Editor probably later in the process.

-- Section 2 --
s/defintion/definition/, I will stop looking for typos, easier to use a spell checker ;)
Barry Leiba Former IESG member
Yes
Yes (for -07) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2019-10-15 for -07) Not sent
I support Roman's DISCUSS.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2019-10-14 for -07) Sent
I think it would be good to note in Section 5.1 that the way the redirect target capability is specified here potentially encourages further use of the EDNS client subnet option to identify the geographic area of a client, which has a number of known privacy drawbacks per RFC 7871 Section 2 and Section 11.1.
Alvaro Retana Former IESG member
No Objection
No Objection (2019-10-16 for -07) Sent
The Abstract and Introduction talk about Open Caching (and specifically about the Open Caching working group of the Streaming Video Alliance (SVA)) as a driving use case for this work...but there are no references to that work, including a description of what Open Caching is.

Open Caching may be well known in the cdni WG and to the interested community, but not to the casual reader...like me.  The document would benefit from referencing the background material.
Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-10-16 for -07) Sent
Section 2

   o  Footprint: The dCDN may want to have a different target per
      footprint.  Note that a dCDN may spread across multiple
      geographies.  This makes it easier to route client requests to a
      nearby request router.  Though this can be achieved using a single
      canonical name and Geo DNS, that approach has limitations; for

We probably want a reference for "Geo DNS".

   A redirect target for DNS redirection is an IPv4 address used as an A
   record response, an IPv6 address used as an AAAA record response or a
   FQDN used as an alias in a CNAME record response (see [RFC1034]) of
   the uCDN DNS router.  Note that DNS routers make routing decisions
   based on either the DNS resolver's IP address or the client IP
   address when EDNS0 client-subnet is used (see [RFC7871]).  The dCDN
   may choose to advertise redirect targets and footprints to cover both
   cases.  [...]
 
We may want to say a bit more about how the dCDN's advertisements
interact with the uCDN's DNS redirection decision here -- is the idea
just that the set of redirect targets should try to be "close to" both
the end-user and recursive resolver IP addresses that will be making
requests of the uCDN?

   The following is an example of a Redirect Target capability object
   serialization that advertises a dCDN target address that is attached
   to a specific list of uCDN "redirecting-hosts".  A uCDN host that is
   included in that list can redirect to the advertised dCDN redirect
   target.  The capabilities object is serialized as a JSON object as
   defined in Section 5 of [RFC8008]

To check my understanding: the Redirect Target capability object is a
new object, in some sense a peer of the (e.g.) Delivery Protocol
capability object, but encoded in a similar fashion as the objects
specified in sections 5.3 through 5.7 of RFC 8008.  In that case, I
wonder if Section 5.2 or 5.1 is a better reference than the top-level
Section 5 of RFC 8008.

Section 2.2

Do we want an example with an IP address as well, to illustrate the full
spectrum of possible behaviors?

Section 2.3

My apologies for not doing much background reading, but what are the
expected scenarios with respect to TLS usage?  Is the redirect expected
to preserve the URI scheme (http:// vs. https://) or could we go from
one to the other as part of the redirect?  (I do see that the example
has an http:// redirection target.)
I ask because there are probably some considerations here relating to
the TLS server name indication, particularly for the case of redirection
to an IP address.

Section 2.4

It's quite possible I've confused myself, but in Figure 1 are the
"redirecting-hosts" and "target host" swapped?  The former is supposed
to be an uCDN host, is it not?

Section 3

   o  Error: A cache may receive a request that it cannot properly
      serve, for example, some of the metadata objects for that service
      were not properly acquired.  In this case, the cache may resolve
      to redirect back to uCDN.

nit: I think this last sentence would benefit from another word or two
or some punctuation to clarify what/how the cache is resolving, e.g.,
quotes around "redirect back to uCDN" or "cache's action" or similar.

   The Fallback target metadata object is used to indicate the target
   address the dCDN should use in order to redirect a client back to the
   uCDN.  Fallback target is represented as endpoint objects as defined
   in section 4.3.3 of [RFC8006].

nit: singular/plural mismatch "target"/"objects"

   The uCDN fallback target address may be used as a DNS A record, AAAA
   record or CNAME record in case of DNS redirection or a hostname for
   HTTP redirect.

nit: I don't think "used as" is quite right (that is, the sense would
apply in the other direction: a DNS A record might be used as a fallback
target address) and could probably be removed.

Section 3.2

[same comment about Figure 3 as for Figure 1 above]

Section 5

The presence of a fallback uCDN host could make for a more tempting
attack target -- if the fallback target is known, then an attacker could
concentrate resources on that fallback host (more effectively DoS'd than
the whole CDN) and thrash the cash on the dCDN to effect a DoS.  This
speaks to the need to keep the exchanged metadata confidential, as
already noted, but is also a latent risk of the topology independently
of keeping the metadata confidential.
The attacks made possible by having the Redirect Target are mostly a
subset of the generic risks listed in RFC 8006; by allowing per-host
granularity of the uCDN behavior, there is perhaps a new opportunity to
have degraded (but present) service, by directing requests to dCDN hosts
that are "far away".  This seems somewhat challenging for an active
attacker to pull off, but may still be the result of misconfiguration.

As I mentioned above, we probably need to say something about TLS usage
for HTTP-level redirection, though I'm not sure yet what exactly that
is, since I don't understand the expected usage yet.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Not sent