Re: IESG position on NAT traversal and IPv4/IPv6

Phillip Hallam-Baker <hallam@gmail.com> Mon, 15 November 2010 17:07 UTC

Return-Path: <hallam@gmail.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 3DD8028C19B; Mon, 15 Nov 2010 09:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level:
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 GNsZ-GaNsM4x; Mon, 15 Nov 2010 09:06:53 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 6AF483A6BC0; Mon, 15 Nov 2010 09:06:53 -0800 (PST)
Received: by gwb10 with SMTP id 10so2992196gwb.31 for <multiple recipients>; Mon, 15 Nov 2010 09:07:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mdGGPqyDPPm4IkJVdMdxfwDKTd5cMtq0fl1LgxPga/k=; b=HpLa7xCKIN3cwRBg+fPgLj4G+jOcLbVaunXYP3xJWjLUJa3UOMmxWQZO9feJJuFgIQ jgEtSODPMKnLkmoQPmLv/zQomFjCbSqQg4RcJGsyckTCbDxDW7t66hlxoOHt+8kZWi1S 1EQEfUGMJ+bp6zmePgfqWR5KPe2r5fyPR5dKs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HLSbz0rwVwy9pikezkUbKHfrCvR2fR+vphdOWK30hdjkaEDBKqqcqTnqq1P2zQjP1S wkJMuViHhm0mJkipc3cqbct4rBIvkb9iLWBoWTsh5bmCmM75Mkt2DhnOI39sRclo2ZKQ 3PnT5S7F6otjZ2CqQ0X4vJU4OP3k3ATPy1SCU=
MIME-Version: 1.0
Received: by 10.100.201.12 with SMTP id y12mr4318802anf.236.1289840854781; Mon, 15 Nov 2010 09:07:34 -0800 (PST)
Received: by 10.100.41.14 with HTTP; Mon, 15 Nov 2010 09:07:34 -0800 (PST)
In-Reply-To: <6AC7D5FA-18D4-4835-9BAD-1545E686CF75@acmepacket.com>
References: <F443844F-67B6-418F-9E32-B2F498686650@acmepacket.com> <AANLkTimnQo=gAXa3FQWWfTp004t-Uv_RDzgOd=30Q49b@mail.gmail.com> <964D24B7092B4686A29005ACBBBCE6C4@23FX1C1> <6AC7D5FA-18D4-4835-9BAD-1545E686CF75@acmepacket.com>
Date: Mon, 15 Nov 2010 12:07:34 -0500
Message-ID: <AANLkTi=SQ1DQ0bBTb7L9RLncoOfeS5aLYk1eMjZSQWqH@mail.gmail.com>
Subject: Re: IESG position on NAT traversal and IPv4/IPv6
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary="0016e68de9b7f750cf04951a799f"
Cc: David Harrington <ietfdbh@comcast.net>, "iesg@ietf.org" <iesg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
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: Mon, 15 Nov 2010 17:07:00 -0000

On Mon, Nov 15, 2010 at 11:41 AM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote:

> Absolutely.  And it should work in environments with IPv6 NATs, and in
> environments with IPv6 firewalls, and in environments with IPv6 consumer
> gateways which block inbound packets until an outbound packet opens a
> pinhole.  All of those fundamentally require the same sort of NAT traversal
> as for IPv4.  None of us have a crystal ball to tell us how IPv6 will end up
> being deployed.
>

That is a good point. Regardless of whether I have NAT for IPv6, I will most
certainly operate with inbound connections disabled by default. That has
saved me against all manner of network worms.

One of the features of Stuxnet was that it attacked certain network attached
printers. I have at least two printers that are more than ten years old and
I could not justify paying the $3500 they would cost to replace new. Neither
is supported by the vendor so patches do not exist.

We really need to have the platform vendors provide an infrastructure to
support authenticated port management so that ports are opened for specific,
permissioned applications and not end up with hosts being thrown into DMZ by
default.



> Having said all that, I'm curious what makes the IESG believe they have the
> authority to impose any such future vision/goal on WG proposed standards.  I
> don't believe RFC 3710, 2026 nor 2418 gives the IESG such discretion.  I
> could be misreading those RFCs, but I believe the criteria the IESG should
> be using are in RFC 2026 sections 4.1.1 and 6.1.2, and they're fairly
> limited.


That should be the function of the IAB. But ever since the infamous Kobe
disaster it has not performed that function and neither has anyone else.

-- 
Website: http://hallambaker.com/