Re: [mif] DNS selection with HE-MIF

Keith Moore <moore@network-heretics.com> Sun, 03 February 2013 16:36 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81AF21F8964 for <mif@ietfa.amsl.com>; Sun, 3 Feb 2013 08:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.134
X-Spam-Level:
X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxdf9PP6bNkO for <mif@ietfa.amsl.com>; Sun, 3 Feb 2013 08:36:19 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 278A021F8703 for <mif@ietf.org>; Sun, 3 Feb 2013 08:36:19 -0800 (PST)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BBD23207CD; Sun, 3 Feb 2013 11:36:18 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Feb 2013 11:36:18 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=6dqloP4xn14xlgh3hkD3M3 Lb0aU=; b=FL/GTgwvTsypRRMhrjjTLSG25u+s7yT/k7K1nb/3OgqNHe+QUaQtv9 Tg5IIND+p+iJF9ACx7jJHxQ/Z7+FAyUKqNabMnVKbJbVLbTaT8bKsDiF69wdBLrz kE7HBSZzg5b1cR8DmQFs8ji8GI09gOL2W0tDjs5ykW8ceEcHItio4=
X-Sasl-enc: KaLk0OVXaegEaVUrF9pSaLoYiHhMYKNGcqTGDQuVMmSf 1359909378
Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id CF4AC8E0917; Sun, 3 Feb 2013 11:36:17 -0500 (EST)
Message-ID: <510E91F5.4030005@network-heretics.com>
Date: Sun, 03 Feb 2013 11:36:05 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <CAM+vMERak2vAoYFeSLRep2xjpm480qPjutyv4-tV=KtU0XO=fw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B630747479BA9@mbx-01.win.nominum.com> <CAM+vMETvE==qUZO2_rhyUB+=ChUR4a9CoTCF+q=gBL2cRA+0UA@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B63074747BB1E@mbx-01.win.nominum.com> <510E8667.3020608@network-heretics.com> <8D23D4052ABE7A4490E77B1A012B63074747BCF6@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BCF6@mbx-01.win.nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] DNS selection with HE-MIF
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Feb 2013 16:36:20 -0000

On 02/03/2013 11:05 AM, Ted Lemon wrote:
> On Feb 3, 2013, at 10:46 AM, Keith Moore <moore@network-heretics.com> wrote:
>> Problem is, this is bad for the Internet architecture, as it basically encourages using DNS as a routing protocol.
> I think using DNS for CDNs is a bad idea, and it's also something that I think people are moving away from, but it is an issue, so I described it.   All of the use cases I described are essentially abuses of the DNS;
agree.
> the question is whether we will spec out something that is robust in the face of these abuses, or whether we will spec out something that simply falls over and dies when people abuse the DNS.
I think this is a case where IETF has failed (over a long period of 
time) to devote sufficient attention to managing the Internet architecture.

In this case, IETF has failed to recognize the cases where people were 
tempted to abuse DNS, and to either adapt DNS or provide alternative 
solutions.   There was little about the Internet architecture, and 
nothing about DNS, that was incompatible with having multiple network 
interfaces on a host.  It's only when DNS is abused that this problem 
crops up.

And now IETF has essentially asked a working group with a very narrow 
scope to fix a fairly broad architectural issue that has been 
exacerbated by 15 or so years of neglect.  Of course, IETF does this all 
the time - MIF isn't the only group that's been asked to patch 
deficiencies in the architecture that were really beyond its proper 
scope.  But this particular issue seems thornier, and to have worse 
long-term consequences, than most.

This is in some sense a structural problem with IETF - its division of 
work into areas based loosely on layers of the protocol stack, and its 
habit of trying to do everything in narrowly-scoped working groups, 
almost entirely precludes resolution of architectural issues, 
particularly when those issues involve conflicts (and require 
compromises) between different layers and/or different interests.

But my point isn't to make a speech.  My point is to say that any real 
solution to this problem is probably beyond a reasonable scope of the 
MIF WG.   Though perhaps MIF could propose a solution as a starting 
point, it should not be trying to define the solution.  It doesn't, and 
cannot, represent a wide enough set of interests to dictate the changes 
that need to occur to DNS and DNS configurations and/or ICMP and/or 
network configurations and/or applications and/or network stacks, to 
resolve this satisfactorily.
> In my mind, these scenarios are essentially DoS attack scenarios: the end user is being attacked by the DNS provider in a provisioning domain, who is giving them corrupt data that will negatively impact their use of the network.   The question is, do we allow that attack to spill over into other provisioning domains, or do we spec out a standard that prevents such spill-over?

Or maybe the thing to do is document the problems, and explain why 
they're architectural issues, and perhaps suggest that IAB and/or IESG 
should undertake to bring a broad set of interests to the table to 
resolve such issues.

Keith