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

[Sebastian Kiesel <[e-mail]>]

Hi Benjamin,

On Wed, Jan 30, 2019 at 09:59:27PM -0600, Benjamin Kaduk wrote:
> Hi Sebastian,
> 
> On Mon, Jan 28, 2019 at 10:28:20PM +0100, Sebastian Kiesel wrote:
> > 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.
> 
> 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.

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 --
> 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,

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
> 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.

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