[alto] Benjamin Kaduk's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)
Benjamin Kaduk <firstname.lastname@example.org> Wed, 19 December 2018 18:36 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F96130E99; Wed, 19 Dec 2018 10:36:18 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, Jan Seedorf <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
Date: Wed, 19 Dec 2018 10:36:18 -0800
Subject: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 18:36:20 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-alto-xdom-disc-04: 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-alto-xdom-disc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3.3's procedures for shortening domain names seem potentially problematic. While I can understand the desire to reduce the number of DNS queries, I'm not sure that it's really appropriate to place restrictions on what prefix lengths/boundaries can be used to divide administrative domains in a standards-track document. In particular, the IPv4 procedure only allows lengths that end on octet boundaries, which seems to ignore the possibility of using procedures from BCP 20. IPv6 is a somewhat different case, but my understanding is that in the general case prefix boundaries can land on arbitrary nibbles, and if we only look at a specific subset for NAPTR records we risk not matching up with reality. The lists in the fourth column of the table in Section 3.4 would presumably need to be revised as well, if this changes. >From Section 5.2.1: We assume that if two organizations share parts of their DNS infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa. subdomains, they will also be able to operate a common ALTO server, Perhaps I am confused, but common subdomains in the reverse zones just implies a common IP address block. Why does it also imply a common DNS infrastructure? I also have a few points relating to the security of DNS and DNSSEC. >From Section 6.1 However, it should also be noted that, if an attacker was able to compromise the DNS infrastructure used for cross-domain ALTO server discovery, (s)he could also launch significantly more serious other attacks (e.g., redirecting various application protocols). I'm not sure that this statement holds as strongly as one might like. In particular, this document is using the reverse zone (whereas normal ALTO usage would seem to only use the forward zone), and my understanding is that the management and operational practices for the reverse zone lag behind that of the forward zone. For example, I have encountered scenarios where I am issued an IPv4 address via DHCP that has no corresponding entry in the reverse zone, which broke some services for me at that site. Protection Strategies and Mechanisms The cross-domain ALTO server discovery procedure relies on a series of DNS lookups. If an attacker was able to modify or spoof any of the DNS records, the resulting URI could be replaced by a forged URI. The application of DNS security (DNSSEC) [RFC4033] provides a means to limit attacks that rely on modification of the DNS records while in transit. [...] I think we need to have a discussion about the efficacy and availability of DNSSEC for the reverse zone (and how those compare to the forward zone). It seems that the situation is less bad than I feared when I deferred the ballot on this document, but perhaps still not in a great place. In particular, I see that IANA and the RIRs do sign their reverse zones, and at least some RIRs have self-service options for inserting DS records into those zones, but my understanding is that in practice signing of the reverse zone is not in great shape. That is, while the technical pieces are all available (and in particular the pieces at the top are all present), it's not currently in any significant usage due to a lack of compelling use case and interest among (e.g.) ISPs. This document does not really seem like it's providing a compelling enough use case to drive adoption, so I think we're forced to treat DNSSEC as not actually useful in practice for this scenario. Separately, there is the question of what trust anchor to use for DNSSEC in the reverse zone for private-use addresses (which can be properly used in multiple locations and have no single point of authority). RFC 7216 includes some text about this issue, which would probably be appropriate to adopt to this case as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I didn't see a response to the secdir review, and agree that discussion of authorization policy would be appropriate. Section 3.1 Does this procedure really make sense for a prefix length of zero (or should the inequalities in the second paragraph have a strict inequality for 0 < L)? In the intended usage scenario, the procedure SHOULD always be called with the parameter SP set to "ALTO:https". [...] This requirement is also stated in Section 2; generally we recommend to not duplicate normative requirements (with 2119 language) in multiple places, to avoid the risk of them getting out of sync. Section 3.2 First, the procedure checks the prefix length L for unsupported values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the procedure aborts and indicates an "invalid prefix length" error to the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "invalid prefix length" error to the caller. Is this in conflict with the inequalities in the second paragraph of section 3.1? If AT=IPv4, a domain name R32 is constructed according to the rules specified in Section 3.5 of [RFC1035] and it is rooted in the special domain "IN-ADDR.ARPA.". RFC1035 doesn't use the term "R32", so some sort of text or typographical clarification that the term is new to this document would be helpful. Similarly for "R128". Section 3.5 The procedure performs one or more DNS lookups in a well-defined order (corresponding to descending prefix lenghts, see Section 3.4), nit: "lengths" Section 4.1 An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix "X" and get a list of one or more IRD URI(s), including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRD(s) will always contain a network and a cost map, as these are mandatory information resources (see Section 11.2 of [RFC7285]). nit: There seems to be a missing transition here, since the IRD URI(s) are URIs, which must be dereferenced or otherwise accessed in order to retrieve the actual IRD(s) (and their network/cost maps). (Similarly for the subsequent sections as well.) nit: we probably need a reference (7285?) for "PID", as well as expansion on first usage. Please also expand ECS on first usage. Accessing cells outside column "X" and row "X" may not yield useful results. nit: I would suggest something like "accessing cells that relate to neither column 'X' nor row 'X'", since the current text could be read to indicate the single cell at their intersection, which is not a terribly interesting cell. Section 5.1.2 Similarly, resource consumers on mobile hosts SHOULD query the resource directory again after a change of IP address, in order to get a list of candidate resource providers that is optimized for the new IP address. Is it really the case that IP address change is the only situation for a mobile host what would cause refresh of the directory information to be advisable? Section 6.1 Note that if TLS is used to protect ALTO, the server certificate will contain the host name (CN). Consequently, only the host part of the HTTPS URI will be authenticated, i.e., the result of the ALTO server discovery procedure. [...] nit: I think this is talking about what happens after the ALTO server discovery procedure; the TLS CN check does not help with verifying the discovery procedure itself. (That is, something like "it only authenticates the result of the ALTO server discovery procedure and not the discovery procedure itself".) Section C.1 The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. However, in the considered scenario of a tracker-based P2P application, there are two fundamentally different possibilities where to place the ALTO client: nit: I think this is the first time that the P2P scenario is mentioned, so more lead-in than just "the considered scenario" might help the reader. In the second scenario (see Figure 4), the resource directory has an Is this Figure 4 or Figure 3? Section C.2 This analysis seems a little one-sided, in that it presents the benefit of tracker-based selection without mention of the additional costs that the tracker bears in this solution (needing to do quality-based selection over the N=10000 total peers instead of random selection). Depending on how that cost scales, the overal best choice may differ.
- [alto] Benjamin Kaduk's Discuss on draft-ietf-a... Benjamin Kaduk
- Re: [alto] Benjamin Kaduk's Discuss on draft-ie... Sebastian Kiesel