Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
draft-ietf-alto-xdom-disc-04

Ballot deferred by Benjamin Kaduk on 2018-12-06.

Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.

Benjamin Kaduk Discuss

Discuss (2018-12-19)
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 (2018-12-19)
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.

Suresh Krishnan Discuss

Discuss (2018-12-05)
* Section 5.1.2.

I am having a hard time seeing how this can be implemented as described.

"Therefore, a dual stack or multihomed resource consumer SHOULD either always use the same address for contacting the resource directory and the resource providers, i.e., overriding the operating system's automatic source IP address selection"

What exactly is the mechanism to be used for the override? A policy table (manual or RFC7078)? I think it would be good if the document can provide an implementable description based on RFC6724.

* Section 3.2.  Step 1

"Similarly, if AT=IPv6 and L < 32, the procedure aborts  and indicates an "invalid prefix length" error to the caller."

I am trying to understand why is this a limitation. An IPv6 prefix can certainly legally have a length of < 32.

(Eric Rescorla) Discuss

Discuss (2018-12-19)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3649


The security considerations for this document don't seem to be
adequate. In general, the security of this mechanism seems to rely on
DNSSEC, and yet it's not mandated.

DETAIL
S 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).

Hmm... Are there no settings in which ALTO servers give information
that isn't something that is a subset of info in DNS? This seems like
it needs more analysis.


S 6.1.
>         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.  The DNS/U-NAPTR
>         based mapping within the cross-domain ALTO server discovery
>         procedure needs to be secured as described above, e.g., by using
>         DNSSEC.

This is not an acceptable description of how to use TLS. Given that
you are using HTTPS, you need to cite 2818. And as this is a new
application of HTTPS, you should be specifying modern TLS, i.e.,
mimimum 1.2 and 7525.


S 6.4.
>         statement [RFC5693] and/or discussed in the ALTO working group,
>         this scenario has not been identified as a relevant threat.
>   
>      Protection Strategies and Mechanisms
>         No protection mechanisms for this scenario have been provided, as
>         it has not been identified as a relevant threat.  However, if a

Another threat here is the disclosure of the exact query you are
making to the ALTO server. An attacker might be interested in that,
and it's not all manifest in the DNS query.
Comment (2018-12-19)
S 2.
>   
>      The service parameter SHOULD always be set to "ALTO:https".  However,
>      other parameter values MAY be used in some scenarios, e.g.,
>      "ALTO:http" to search for a server that supports unencrypted
>      transmission for debugging purposes, or other application protocol or
>      service tags if applicable.

What would be applicable here?


S 2.
>      The discovery procedure sequentially tries two different lookup
>      strategies: First, an ALTO-specific U-NAPTR record is searched in the
>      "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
>      corresponding to the given IP address or prefix.  If this lookup does
>      not yield a usable result, the procedure tries further lookups with
>      truncated domain names, which correspond to shorter prefix lengths.

Seems like wildcards could get a lot of this, no?


S 3.4.
>      | IPv4       |        32  |  R32       | R24, R16, R8               |
>      | IPv4       |  24 .. 31  |  R24       | R16, R8                    |
>      | IPv4       |  16 .. 23  |  R16       | R8                         |
>      | IPv4       |   8 .. 15  |   R8       | (none)                     |
>      | IPv4       |   0 ..  7  | (none, abort: invalid prefix length L)  |
>      +------------+------------+------------+----------------------------+

I'm trying to work out how this works. Say that AT=IPv4 and L=27, so
we have like ff.ff.ff.ff/28 (I know this is illegal, but it saves me
on math). My first look up should be: 240.255.255.255.in-addr.arpa,
and then my next one should be 255.255.255.in-addr.arpa? Is that
correct?

Where does the text say that I should zero the low-order bits in R32?




S 3.4.
>      | IPv6       | 64 (..127) |  R64       | R56, R48, R32              |
>      | IPv6       |  56 .. 63  |  R56       | R48, R32                   |
>      | IPv6       |  48 .. 55  |  R48       | R32                        |
>      | IPv6       |  32 .. 47  |  R32       | (none)                     |
>      | IPv6       |   0 .. 31  | (none, abort: invalid prefix length L)  |
>      +------------+------------+------------+----------------------------+

What's the reasoning for this pattern?


S 5.1.1.
>      mechanisms such as STUN [RFC5389] would be needed and considerations
>      for UNSAF [RFC3424] apply.  Therefore, using the procedures specified
>      in this document for resource consumer based ALTO server discovery is
>      generally NOT RECOMMENDED.  Note that a less versatile yet simpler
>      approach for resource consumer initiated ALTO server discovery is
>      specified in [RFC7286].

Why can't people do STUN?

Mirja Kühlewind Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-12-05)
Thanks for a very readable draft, especially given the that we are talking about naptr stuff :-)

I agree with Alissa's comment.

§2, 4th paragraph: "The service parameter SHOULD always be set to "ALTO:https"."
That SHOULD is redundant to the similar requirement in §3.1. Since that section describe the detailed procedures, I suggest leaving the normative keywords to it, and using descriptive language here.

Alissa Cooper No Objection

Comment (2018-12-05)
Section 6.4: It seems that people's understanding of the kind of threat described in this section has changed somewhat since 2009 when RFC 5693 was published. For example, work to provide confidentiality protection for DNS client requests to recursive resolvers (DoT and DoH) has occurred in the time since then, and the information revealed by such requests is arguably less sensitive than the information sent by ALTO clients. I don't know if the applicability of DoT/DoH to NAPTR has been written about anywhere, but at a minimum it seems that this is worthy of some discussion here.

(Spencer Dawkins) No Objection

Comment (2018-12-05)
In this text, 

   One such scenario is detailed in
   Appendix C.

there are several scenarios in Appendix C. I THINK you may want me to look at Appendix C.3, which is an example, which is fine, but whether that's what you want me to look at or not, it would be useful to point more specifically at what you're thinking about.

Warren Kumari (was Discuss) No Objection

Comment (2018-12-19)
Thank you for educating me :-) 
(previous position was discuss because I didn't understand the deployment scenario).

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-12-05)
I concur with Alissa's comment.

Martin Vigoureux No Objection

Roman Danyliw No Record

Barry Leiba No Record

Éric Vyncke No Record

Magnus Westerlund No Record