Re: existing (and questionable) application designs [was Re: US DoD and IPv6]

Keith Moore <moore@network-heretics.com> Fri, 08 October 2010 12:59 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A201D3A68A2 for <ietf@core3.amsl.com>; Fri, 8 Oct 2010 05:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level:
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Gx1njaPBYVU for <ietf@core3.amsl.com>; Fri, 8 Oct 2010 05:59:46 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id C047D3A689E for <ietf@ietf.org>; Fri, 8 Oct 2010 05:59:46 -0700 (PDT)
Received: from 108-108-252-221.pools.spcsdns.net (108-108-252-221.pools.spcsdns.net [108.108.252.221] (may be forged)) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id CGU86588 (AUTH admin@network-heretics.com); Fri, 8 Oct 2010 06:00:42 -0700
X-Mirapoint-Received-SPF: 108.108.252.221 108-108-252-221.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.252.221 108-108-252-221.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.252.221 108-108-252-221.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.252.221 108-108-252-221.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.252.221 108-108-252-221.pools.spcsdns.net <moore@network-heretics.com> 5 none
Subject: Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <AANLkTina_0HuTu1h7nNsYurRMivXnaqPGvAD9UvMo3kn@mail.gmail.com>
Date: Fri, 08 Oct 2010 09:00:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAE49FC8-FE20-4F2B-B209-1CAD68657612@network-heretics.com>
References: <20101006150059.E2DB76BE567@mercury.lcs.mit.edu> <29CA87B0-2C3C-4FBF-8682-0616B648F0AE@network-heretics.com> <4CACB070.1070501@gont.com.ar> <DE24B5F5-31FF-45E1-A99E-74AB9C9F17D6@network-heretics.com> <AANLkTi=9Dvs51BH2yZ8W467Q8zO3rU=WHDmDKKf=bB2n@mail.gmail.com> <E82F3E3F-DFAF-421B-8E57-8185E1D9CB2E@network-heretics.com> <4CAD1AFA.7080701@gont.com.ar> <4CAD1FBD.8080406@gmail.com> <AANLkTina_0HuTu1h7nNsYurRMivXnaqPGvAD9UvMo3kn@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: ietf@ietf.org, Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2010 12:59:47 -0000

> The referral problem he refers to is real, but I see it more as a consequence of the IETF being too rigid in its approach to address numbering.

How would changing IETF's approach to address numbering help the referral problem?

> The basic question here is that we have two hosts that are to connect for a peer-peer protocol in which either endpoint can initiate or respond to a connection request.
> 
> 
> Clearly this is rather challenging if the boundaries between addressing schemes are arbitrary and becomes somewhat simpler in a uniform addressing model.
> 
> But the real Internet is not like that. It is a network of networks and crossing the boundary between a private network and the interconnect space between the networks has consequences.
> 
> One of those consequences is that addresses can change at the private/interconnect border. Another consequence is that crossing that boundary should have security consequences.

In the "real" Internet, the boundary between a private network and "the interconnect space" is fuzzy and arbitrary, especially from a security point-of-view, and becoming moreso all the time. 

> Opening up a port to receive connection requests has considerably greater security consequence than making the request. The requester is opening a communication channel with a single, specified entity, the responder is opening access to any host on the Internet.

And far better mechanisms than "opening up a port" are feasible even within the classic Internet architecture.  If the industry hasn't provided them, that's not the fault of the architecture.

> So opening a port is an event that should be mediated by access control at the host level and private/interconnect border at a minimum. In a default deny network there will be additional policy enforcement within the private network. 

There's a fundamental problem in that people have come to expect that somehow the network is responsible for keeping hosts secure from attack.  Again, that's not the fault of the architecture.

Keith