Subject: [alto] Benjamin Kaduk's and Eric Rescorla's Discusses on draft-ietf-alto-xdom-disc-04

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 28 Jan 2019 22:28:20 +0100

Hi Benjamin and Eric,

both of you have entered a Discuss on draft-ietf-alto-xdom-disc-04,
because the current version of the document does not make usage of
DNSSEC mandatory (and because of further issues, which we will address
in separate mails, respectively).  However, we (the authors) believe
that the two positions are not completely aligned.  After internal
discussion and consultations with our AD we propose the following change
regarding the use of DNSSEC (for a complete new version of sec. 6.1
please see at the end of this mail):

    All implementations of the cross-
    domain ALTO server discovery procedure MUST support DNSSEC or be
    able to use of such functionality in the underlying operating
    system.  Network operators that publish U-NAPTR resource records
    to be used for the cross-domain ALTO server discovery procedure
    SHOULD use DNSSEC to protect their subdomains of in-addr.arpa.
    and/or ip6.arpa., respectively.

Would that proposal address your concerns adequately?

Thanks
Sebastian

----- Begin proposal for new section 6.1 -----

6.1.  Integrity of the ALTO Server's URI

   Scenario Description
      An attacker could compromise the ALTO server discovery procedure
      or the underlying infrastructure in a way that ALTO clients would
      discover a "wrong" ALTO server URI.

   Threat Discussion
      The cross-domain ALTO server discovery procedure relies on a
      series of DNS lookups, in order to produce one or more URI(s).  If
      an attacker was able to modify or spoof any of the DNS records,
      the resulting URI(s) could be replaced by forged URI(s).  This is
      probably the most serious security concern related to ALTO server
      discovery.  The discovered "wrong" ALTO server might not be able
      to give guidance to a given ALTO client at all, or it might give
      suboptimal or forged information.  In the latter case, an attacker
      could try to use ALTO to affect the traffic distribution in the
      network or the performance of applications (see also Section 15.1.
      of [RFC7285]).  Furthermore, a hostile ALTO server could threaten
      user privacy (see also Section 5.2.1, case (5a) in [RFC6708]).

   Protection Strategies and Mechanisms
      The application of DNS security (DNSSEC) [RFC4033] provides a
      means to detect and avert attacks that rely on modification of the
      DNS records while in transit.  All implementations of the cross-
      domain ALTO server discovery procedure MUST support DNSSEC or be
      able to use of such functionality in the underlying operating
      system.  Network operators that publish U-NAPTR resource records
      to be used for the cross-domain ALTO server discovery procedure
      SHOULD use DNSSEC to protect their subdomains of in-addr.arpa.
      and/or ip6.arpa., respectively.  Additional operational
      precautions for safely operating the DNS infrastructure are
      required in order to ensure that name servers do not sign forged
      (or otherwise "wrong") resource records.  Security considerations
      specific to U-NAPTR are described in more detail in [RFC4848].

      In addition to active protection mechanisms, users and network
      operators can monitor application performance and network traffic
      patterns for poor performance or abnormalities.  If it turns out
      that relying on the guidance of a specific ALTO server does not
      result in better-than-random results, the usage of the ALTO server
      may be discontinued (see also Section 15.2 of [RFC7285]).

   Note
      The cross-domain ALTO server discovery procedure finishes
      successfully when it has discovered one or more URI(s).  Once an
      ALTO server's URI has been discovered and the communication
      between the ALTO client and the ALTO server starts, the security
      threats and protection mechanisms discussed in the ALTO protocol
      specification [RFC7285] apply.

      A threat related to the one considered above is the impersonation
      of an ALTO server after its correct URI has been discovered.  This
      threat and protection strategies are discussed in Section 15.1 of
      [RFC7285].  The ALTO protocol's primary mechanism for protecting
      integrity (and confidentiality) is the use of HTTPS-based
      transport, i.e., HTTP over TLS [RFC2818].  Typically, when the
      URI's host component is a host name, a further DNS lookup is
      needed to map it to an IP address, before the communication with
      the server can begin.  This last DNS lookup (for A or AAAA
      resource records) does not necessarily have to be protected by
      DNSSEC, as the server identity checks specified in [RFC2818] are
      able to detect DNS spoofing or similar attacks, after the
      connection to the (possibly wrong) host has been established.
      However, this validation based on the server certificate can only
      protect the steps that occur after the server URI has been
      discovered.  It cannot detect attacks against the authenticity of
      the U-NAPTR lookups needed for the cross-domain ALTO server
      discovery procedure, and therefore, these resource records have to
      be secured using DNSSEC.

----- End proposal for new section 6.1 -----

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Jan 2019 21:59:27 -0600

Hi Sebastian,

>     and/or ip6.arpa., respectively.

While that is sound advice, and we cannot realistically make stronger
mandates to use DNSSEC, I don't think it fully captures the extent of at
least my DISCUSS.  (Perhaps this falls into the "further issues" that will
be addressed separately?  Let me know if that's the case.)

In particular, I want to be sure that DNSSEC is available as a realistic
option in all possible ALTO deployments.  There are two prongs to this --
availability of DNSSEC in the reverse zone for private-use addresses (my
final DISCUSS point), and reliance on third parties for DNSSEC in the
reverse zone (my penultimate point).

To illustrate the latter with an example, at home, my residential ISP gives
me an IP address via DHCP.  My ISP does not give me an interface to adjust
the entries for my address in its reverse zone, and while my particular ISP
does appear to sign the reverse zone, can we guarantee that all such ISPs
will do so?  I do not have leverage against my ISP to make them offer me a
way to create NAPTR records for my assigned IP address (e.g., since I have
to use DHCP and am not contracted for a fixed IP allocation), so ALTO
cross-domain discovery would not be usable for me at home if I was running
a service that would merit it (which would, of course, be forbidden by my
terms of service anyway).  By publishing this document, we are in effect
making a claim that the availability both of DNSSEC for the reverse zone by
transit providers, and the availability of interfaces to allow insertion of
(NAPTR) records into the reverse zone by those same transit providers, is
sufficently well advanced that it will be usable for a large fraction of
the ALTO target audience.  It's not clear to me what grounds we have to
support such a claim, and that's what I'm trying to get at with my
penultimate DISCUSS point.  Part of this will depend on what exactly the
ALTO target audience is, of course, and consequently the ISPs they are
likely to be using.

Does that help clarify my thinking?

Thanks,

Benjamin

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 31 Jan 2019 22:30:31 +0100

Hi Benjamin,

On Wed, Jan 30, 2019 at 09:59:27PM -0600, Benjamin Kaduk wrote:
> option in all possible ALTO deployments.

First of all, I think that the ALTO cross-domain server discovery
procedure will not be useful for *all* possible ALTO deployments. There is
already one ALTO server discovery mechanism specified in RFC 7286.
But there is at least one significant class of deployment scenarios
where RFC 7286 is not optimal (see appendix C of our document) and where
the ALTO cross-domain server discovery procedure comes very handy.  That
being said, we should make sure that DNSSEC is a realistic option for
all realistic use cases.

> There are two prongs to this --
> the entries for my address in its reverse zone,

In the use case we have in mind, that would not be a bug, but more a feature.

The idea is, that "the operator of the access network" (see below)
publishes information about network topology and routing costs - from
their perspecive (!) - through their ALTO server, which can be queried
using the HTTPS-based ALTO protocol.

If a host in your home network takes part in a overlay topology of some
sort (peer-to-peer network, content delivery network, etc.) that overlay
network will consume ALTO information and shape the overlay topology and
manage the traffic distribution in the overlay accordingly, hopefully
causing a win-win situation: better performance in the overlay and less
resource consumption / cost in the underlying network infrastructure.
That (assumed) win-win situation is also the incentive to take part in
ALTO.  If the overlay-shaping-and-routing (or peer selection) process
takes place in your host at home, you can use RFC 7286 to find an ALTO
server (or use STUN + cross-domain discovery on your own external IP
address).  If however, a third party in a remote domain (e.g.,
redirectors in CDNs, P2P tracker,, etc) does that
overlay-shaping-and-routing on behalf of your host, it will have to use
cross domain discovery. 

(see Appendix C for a longer description of an example scenario).

So who is "the operator of the access network" who publishes the
NAPTR linking an IP address to an ALTO URI?

In your example, I would say it is the residential ISP, not you, even
if you operate a residential gateway and a RFC1918 network with more
than one host behind that gateway.  As long as your network is only
single homed and you have a default route and a "flat rate" or
volume-based charging that does not differentiate between targets, you
are probably not the target audience for publishing ALTO information.

On the other hand, a regional ISP or the IT department of a
medium- to large-sized company, who do use different upstream
links/carriers/pricing depending on the destination, are what we
have in mind. They probably have got a delegation of their subdomains
of in-addr.arpa./ip6.arpa. or at least they should be able to get
them, if they want to use this scheme. Pure transit providers that are
not close to the access networks with the hosts are not interesting for us.

Speaking of RFC1918 addresses: If your home network uses RFC1918
addresses but the outside interface of your residential gateway
has a public IP address, an ALTO-optimization based on that public
address is sufficient for the optimization of Internet-wide overlay
topologies. For the internal optimization of a larger topology
with RFC1918 addresses (e.g., high performance computing cluster)
I'd rather go for RFC 7286 based discovery or publish the ALTO
server's URI through cluster/OS configuration management. A bit more
interesting is the case of a large access network behind a carrier grade
NAT. There I'd use both mechanisms to point both internal and external
ALTO clients to the same ALTO server URI, and let that ALTO server
twist his mind on how internal and external optimization have to work
together for best overall results.

> and while my particular ISP

I see two related but separate claims or issues here:

1.  ALTO cross-domain server discovery *is* useful even if most
residential or mobile users cannot control the reverse DNS for their
(dynamic) IP address. It is enough when the delegation of the reverse
zone gets close to the edge, to the residential ISP, mobile network
operator, or the corporate IT department (see above).  We think that is
widely implemented or at least doable.

2.  Can DNSSEC be used to protect reverse DNS queries?
The technology is available (proof by example).

Will ISPs actually use it, or will they take chances? I think the risks
of wrong (forged) guidance are quite manageable and there is little
benefit for an attacker to do so. Should attacks become widespread, ISPs
can start using DNSSEC quickly without changing code in the clients.  So
maybe we can make sure that the technology is available and RECOMMEND
to use it, but ultimately let the operators decide whether to use it?

> Does that help clarify my thinking?

Yes, it did. Thanks. I hope my reply is useful, too. Should we try
to incorporate parts of it into the document?

Thanks,
Sebastian