Re: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

Warren Kumari <warren@kumari.net> Thu, 19 July 2018 17:38 UTC

Return-Path: <warren@kumari.net>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A95130EAF for <behave@ietfa.amsl.com>; Thu, 19 Jul 2018 10:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 etkEUCSQAmfp for <behave@ietfa.amsl.com>; Thu, 19 Jul 2018 10:38:39 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31B8120049 for <behave@ietf.org>; Thu, 19 Jul 2018 10:38:38 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id z13-v6so7226122wma.5 for <behave@ietf.org>; Thu, 19 Jul 2018 10:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YaWIWD146MQ8bUD3eKuK8u++4wXx+oUZalILhq/RWr8=; b=yZgW3f+aEPc0uWbizsEpyTu2Vostfu4F39sQ8gQowSQhqstXQk93UB33nw6l0uyHEd TzbPJA2shjUeMNANA+4ju47yVF0iKAAdyWXvDjGUQbps70ArUhYK66caDz6tctjQIm2P o3cy/XztiVnXVgFMktThq3x5SdHi/PPapgDzabyi8DFeK2d3M3wAyAcXxqZNjh3B2Z7G xiVCqchlNP/imEQ6oHiV2UIws7ColOEBqBRwhhqWS3DjBxyM5bSddGZMQLg/Wcq9nel8 W4zckc4GVN5rWJX2Z/qv84iDUh5CJvM9X4orJ/4P77GkI/YGysY6KjjR3tB36g2XTfn6 N5XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YaWIWD146MQ8bUD3eKuK8u++4wXx+oUZalILhq/RWr8=; b=cLPppbmqsWaMc+gjzrnw3e6ak7xXfpnWwoAMwV+6LaHH+PxsHSiOF1AA8C3UoA8tso ojAU4QxbjRbuxqjNpEuZ0eNR/J2PjKiKFVqJhRgZnJLAK8QqTuMxiNiRWqnlP60Cosuj ioRwrFn05WLJX4RhL4RnhXqq4n3ancfkmexcNL3dCjmPZiZPgQEgggT0aNbLiZXB49Lz yAAc1HDlKurFfsyRgWI9kttB/3BE+Kyba5Jye4OmhVVfyONP010MibVyKsaoDvXNs/8d mdiqGzw8b+1mSOIAEiPuS/g0YXPMGb7L34u3iqJ4+lKwZ5io3RzaY2pYdcv+GSahAeoU nQbQ==
X-Gm-Message-State: AOUpUlH0GiVaJtH+qfEkpnzM15UR7elQOzvEv69RuPD0xpODHhBRrEkE jDmzBrqREI6f7eR2eM+bzdJl6Fyj2ilBjxKB7hyC+A==
X-Google-Smtp-Source: AAOMgpfbTye6MGqeAiP+cG2qfgcU/tW0/SepLEGWksrh7mkigAqgF8D4KIHUVUsL7524FjAmce1fP9qM8CkV3RvbGXo=
X-Received: by 2002:a1c:87c9:: with SMTP id j192-v6mr4501131wmd.71.1532021917081; Thu, 19 Jul 2018 10:38:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com> <CAHw9_i+UPqExtwJPFSbWsxn41v52kUavq=VOxJ=R6TGCbHm8Gg@mail.gmail.com> <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net>
In-Reply-To: <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 19 Jul 2018 13:38:01 -0400
Message-ID: <CAHw9_iJn8q8K4dHgrcT33s0u2Cb-8cudBss8fzUvXSMvd3RmoA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: behave@ietf.org, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/SWdbv6KdTS9tUObUyauIICkgnSk>
Subject: Re: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 17:38:44 -0000

[ + DNSOP ]


On Mon, Jul 16, 2018 at 4:15 PM Christian Huitema <huitema@huitema.net> wrote:
>
> I have never been a great fan of the DNS64 hacks. The DNS64
> specification, and RFC7050, are making a set of assumptions about the
> DNS infrastructure, the way stub resolvers are configured, and the
> possibility for intermediate resolvers to spoof AAAA records on the fly.
>
> One of these assumptions was already on shaky ground when the spec was
> written. It is only OK to spoof DNS records if the clients do not insist
> on DNSSEC. I don't have good numbers on clients, by I see measurements
> showing that over 90% of clients are served by recursive DNS resolvers
> that request DNSSEC validation (setting the DNSSEC OK option flage to
> 1), and over 50% of clients are served by recursive DNS resolvers that
> perform DNSSEC validation.
>
> Another assumption is that clients use DNS resolvers that are under the
> control of the network provider. Again, current measurement show that
> more than 25% of clients are server by third party DNS resolvers. That
> number is actually growing steadily. New DNS transports like DNS over
> TLS or DNS over HTTPS ensure that the exchanges between clients and
> third party resolvers will be pretty much immune to hacking by on-path
> middleboxes.
>
> Yet another assumption is that clients expect DNS responses to vary
> depending on the interface over which the DNS queries are sent. Again,
> this is incompatible with the current trend of using third party
> resolvers. That assumption might have worked when applications were only
> using DNS resolvers provided by the operating system. But then, we see a
> solid trend of moving transport services out of the kernel and into
> application libraries. QUIC is an example of that.
>
> These numbers and these trends tell me that technologies like DNS64 will
> be very hard to deploy, and also very unreliable when deployed. These
> technologies make a number of unwarranted assumptions about the nature
> of the DNS service. I don't think that attempting yet another patch like
> ipv4only.arpa will help all that much. In fact, I would much prefer to
> let 7050 die a deserved death, and maybe hasten that death by
> deprecating its status.

RFC7050 is already widely deployed -- I must admit that I personally
also view it as a hack, but I'd much rather that, as it will continue
to be used, it is at least well described, and has less pointy edges
on it....

W
>
> -- Christian Huitema
>
>
>
> On 7/15/2018 7:20 PM, Warren Kumari wrote:
> > Dear BEHAVE,
> >
> > I sent this to DNSOP a while back, but didn't think to send it to
> > behave as well - sorry.
> >
> > Please see below, and if you have comments, please comment in the
> > DNSOP list (so that we don't have overlapping discussions)...
> >
> >
> > Thank you!
> > W
> >
> >
> > ---------- Forwarded message ---------
> > From: Warren Kumari <warren@kumari.net>
> > Date: Wed, Jul 4, 2018 at 4:26 PM
> > Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
> > To: dnsop <dnsop@ietf.org>
> >
> >
> > Dear DNSOP,
> >
> > Stuart Cheshire & David Schinazi have asked me to AD sponsor the
> > draft-cheshire-sudn-ipv4only-dot-arpa document
> > [0]
> > ..
> >
> > >From the document:
> > "The specification for how a client discovers its network's NAT64
> > prefix [RFC7050] defines the special name 'ipv4only.arpa' for this
> > purpose, but declares it to be a non-special name in that
> > specification Domain Name Reservation Considerations section.
> > Consequently, despite the well articulated special purpose of the
> > name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names
> > registry as a name with special properties.
> > This document formally declares the actual special properties of the
> > name, and adds similar declarations for the corresponding reverse
> > mapping names."
> >
> > RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address
> > Synthesis") is worth reading before reading this. If you are mainly a
> > DNS person,
> > this may be...surprising.
> >
> >
> > When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things
> > worth
> >  keeping in mind:
> >
> > 1: This is a fairly specialized function - it is used by NAT64 clients
> > to discover the prefix used for synthesis ("normal" people /
> > applications never need to resolve this). The main people who will
> > deal with this are mobile / stack vendors, and NAT64 providers.
> > 2: RFC7050 has a large amount of text around DNSSEC, what to do with
> > DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64
> > device*, not the ipv4only.arpa name.
> > 3: Devices use this mechanism to discover the IPv6 prefix used for
> > IPv6 address synthesis - different interfaces (e.g cellular and wifi)
> > will have different prefixes. This means that clients
> > must
> > do this query using the resolver learned on / appropriate for that
> > interface. This is the main bit which is weird for a DNS person - the
> > response from the resolver for your cellular interface connected to
> > T-Mobile contains T-Mobile's NAT64 prefix; the response from the
> > resolver learnt over your wifi connection to the IETF network contains
> > the NAT64 prefix you use on the IETF network. DNS isn't really being
> > used here for resolving names, rather DNS is being used a signalling
> > mechanism (a rude t-shirt springs to mind here).
> >
> > What this draft does is:
> > 1: record this in
> > the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't
> > actually ask the IANA to update the registry.
> > 2: requests that the IANA make ipv4only.arpa be an insecure delegation
> > (see #2 above) -
> > this removes some special handling and complexity.
> >
> > 3: specifies that you have to use the resolvers learn on an interface
> > for these queries. The whole purpose of these queries is to learn the
> > *local* NAT64 prefix - asking a public recursive isn't going to help
> > you here.
> > 4: This is under .arpa (and is already in wide use) - it doesn't have
> > the sticky policy problems that many SUD names have.
> >
> > I've
> > agreed
> >  to AD sponsor this, but would really appreciate your review and
> > input. RFC7050 is deployed - this improves / clarifies things.
> >
> > 1: The authors have previously presented this document at DNSOP
> > meetings - there was some discussion, but no real interest in adopting
> > or shouts of outrage about it.
> > 2: I've asked the DNSOP chairs if I can use the DNSOP list for
> > discussion of this
> > (and they agreed)
> > 3: This was originally a product of the (now closed) BEHAVE WG - I've
> > spoken with Spencer (the BEHAVE AD) who has no objections.
> > 4: I've asked the IESG and there were no objections either.
> > 5: As this touches .arpa I'm also asking the IAB for input.
> > 6: Dave Thaler (who was the document shepherd for RFC7050) has kindly
> > agreed to be shepherd for this document too.
> >
> > W
> >
> > [0]: note that they asked this before the current "ipv4only.arpa's
> > delegation should be insecure." thread -
> > https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY
> >
> > --
> > I don't think the execution is relevant when it was obviously a bad
> > idea in the first place.
> > This is like putting rabid weasels in your pants, and later expressing
> > regret at having chosen those particular rabid weasels and that pair
> > of pants.
> >    ---maf
> >
> >
> > --
> > I don't think the execution is relevant when it was obviously a bad
> > idea in the first place.
> > This is like putting rabid weasels in your pants, and later expressing
> > regret at having chosen those particular rabid weasels and that pair
> > of pants.
> >    ---maf
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
>
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf