[CDNi] Benjamin Kaduk's No Objection on draft-ietf-cdni-request-routing-extensions-07: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 16 October 2019 21:16 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: cdni@ietf.org
Delivered-To: cdni@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 082A21201EF; Wed, 16 Oct 2019 14:16:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cdni-request-routing-extensions@ietf.org, Kevin Ma <kevin.j.ma.ietf@gmail.com>, cdni-chairs@ietf.org, kevin.j.ma.ietf@gmail.com, cdni@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.105.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <157126059402.7932.18184605997089219715.idtracker@ietfa.amsl.com>
Date: Wed, 16 Oct 2019 14:16:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/kAsSxmuSJ9oXz1BIrRZ3XR3PPvI>
Subject: [CDNi] Benjamin Kaduk's No Objection on draft-ietf-cdni-request-routing-extensions-07: (with COMMENT)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 21:16:34 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-cdni-request-routing-extensions-07: 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-request-routing-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
- [CDNi] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [CDNi] [E] Benjamin Kaduk's No Objection on d… sanjay.mishra