Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)
Sebastian Kiesel <ietf-alto@skiesel.de> Mon, 25 February 2019 22:01 UTC
Return-Path: <ietf-alto@skiesel.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17A512D827; Mon, 25 Feb 2019 14:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKSZG7-01W_v; Mon, 25 Feb 2019 14:01:04 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31761286E7; Mon, 25 Feb 2019 14:01:03 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de ([2a02:a00:e000:116::41]:47120) by gw01.ehlo.wurstkaes.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ietf-alto@skiesel.de>) id 1gyOJ1-0003bM-3P; Mon, 25 Feb 2019 23:00:59 +0100
Date: Mon, 25 Feb 2019 23:00:54 +0100
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-alto-xdom-disc@ietf.org, Jan Seedorf <jan.seedorf@hft-stuttgart.de>, alto-chairs@ietf.org, alto@ietf.org
Message-ID: <20190225220054.cszrsxaxnjjrlyep@gw01.ehlo.wurstkaes.de>
References: <154524457894.1855.6608728646445604851.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <154524457894.1855.6608728646445604851.idtracker@ietfa.amsl.com>
Organization: my personal mail account
Accept-Languages: en, de
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/abNdzuFOYjNhXApamrusVjySmEM>
Subject: Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Feb 2019 22:01:08 -0000
Hi Benjamin, please find below our responses to your questions and concerns, except those related to authenticity and the usage of DNSSEC. For the latter I have started a separate thread, so we can hopefully find a solution that addresses both your and Erik's concerns. On Wed, Dec 19, 2018 at 10:36:18AM -0800, Benjamin Kaduk wrote: > 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. The current procedure specification tries to make a compromise between flexibility and avoiding excess load on the DNS. For the intended use case it is not a primary concern to find out the exact prefix lenghts that have been delegated. If, say, I am the owner of a IPv4 /17, I can either try to make an agreement with the owner of the other half of the /16 (if the delegation structure is that way) and jointly run one ALTO server for the /16, or I can add 128 NAPTRs, one for each /24 in my range, that point to my ALTO server. Both methods would work for our use case. The exact prefix lengths for which we do a query (/32, /24, /16 for IPv4 and /128, /64, /56, /48, /32 for IPv6) were taken from RFC 7216. Maybe we should add /40 to the IPv6 list, for a regular spacing between the steps, but not significantly more to avoid an excess number of queries? > 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. In the intended use case (of ALTO XDOM DISC, not overall ALTO that has a broader applicability) we assume that single-homed networks (in particular the residential DSL/cable subscribers) will normally not want to publish their own ALTO information but will leave that up to their upstream ISP. Although ALTO is by no means technologically tied to BGP, we anticipate that BGP will be the most important information source and that the operator of the outermost BGP-enabled router will have the most incentives to publish a digest of his routing policies and costs through ALTO to the application overlays. In these scenarios, IPv4 prefix lengths > 24 do not matter. That being said, the procedure is compatible with BCP20: For 1.2.0.192.in-addr.arpa. IN CNAME 1.0/25.2.0.192.in-addr.arpa. 1.0/25.2.0.192.in-addr.arpa. IN PTR host1.A.domain. you could add 1.0/25.2.0.192.in-addr.arpa. IN IN NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto1.A.example.net/ird!" . > 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? This paragraph has BCP 20 in mind. What we want to say is that if you use BCP 20, there will be someone who gets the reverse DNS delegation for the /24 and who has to setup all that CNAMES in his name servers. So BCP 20 implies a little bit more interaction and trust than just getting a domain for the /24 delegated. Maybe the organizations involved in that can also jointly run one ALTO server and everyone may feed his ALTO information into it. Or, they may use CNAMES to put NAPTRs on the /32, or they leave the ALTO configuration their upstream ISP (see above). I'll try to find a better wording. > I also have a few points relating to the security of DNS and DNSSEC. Please let's discuss these issues in the other mail thread, to address Erik's concerns, too. > ---------------------------------------------------------------------- > 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)? This will be addressed in the new version of the draft. Syntactically valid is 0 <= L <= 32 (v4) or 0 <= L <= 128 (v6). Supported by the procedure is 8 <= L <= 32 (v4) or 32 <= L <= 128 (v6). > > 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. This will be addressed in the new version of the draft. > 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? see above. > > 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". Thanks for pointing this out. This will be addressed in the new version of the draft. > 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. OK. I thought there were enough references to RFC 7285 in the first paragraph of section 4 to make clear that we assume the reader is familiar with the key concepts of RFC 7285 (Actually this is true for the whole document). > 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. Thanks for pointing this out. This will be addressed in the new version of the draft. > > 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? Do you have a particular scenario in mind that we might have forgotten? > > 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".) correct. the intent is to explain why in the world wide web, we can use DNS-without-DNSSEC and later validate the result with the cert, but not here. We'll rewrite that paragraph a bit. > > 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? both ... see Figures 3 and 4 > 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. Well, this is true for (almost?) every ALTO use case. Do some addtional effort to choose your communication partners, get better performance in the overlay and cause less resource consumption in the underlying infrastructure. This only pays off for larger data transmissions, but there, it will. Thanks for pointing out these nits! Sebastian
- [alto] Benjamin Kaduk's Discuss on draft-ietf-alt… Benjamin Kaduk
- Re: [alto] Benjamin Kaduk's Discuss on draft-ietf… Sebastian Kiesel