Re: Reminder: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010

Lars Eggert <lars.eggert@nokia.com> Wed, 01 December 2010 13:17 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D29428C215 for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 05:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.253
X-Spam-Level:
X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100]
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 BTZDcOW+oUXr for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 05:17:53 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 1C08828C239 for <tsvwg@ietf.org>; Wed, 1 Dec 2010 05:17:53 -0800 (PST)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB1DIxPq013839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 15:19:00 +0200
Subject: Re: Reminder: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary=Apple-Mail-43--630285474; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4CF6448A.3000601@cisco.com>
Date: Wed, 1 Dec 2010 15:18:46 +0200
Message-Id: <CA362307-5B37-49FF-A9C1-029A233E9AB0@nokia.com>
References: <4CE573AC.6050708@erg.abdn.ac.uk> <p06240827c9108fb7d7f0@[10.20.30.150]> <4CED3A82.5050708@ericsson.com> <p0624089fc912ec9557a7@[10.20.30.150]> <4CF60F04.60101@ericsson.com> <4CF6252A.2020303@cisco.com> <BB803922-E3CD-4B26-9467-8BB14B259D3F@nokia.com> <4CF6448A.3000601@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.1082)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 01 Dec 2010 15:18:52 +0200 (EET)
X-Nokia-AV: Clean
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Paul Hoffman <paul.hoffman@vpnc.org>, tsvwg WG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 13:17:55 -0000

Hi,

On 2010-12-1, at 14:50, Eliot Lear wrote:
> On 12/1/10 12:05 PM, Lars Eggert wrote:
>> I agree with you that the reasons for having separate port ranges are bogus, but the *reality* is that it *matters* whether your port is above or below 1024 on many deployed systems. And hence it matters for applicants what number they get.
> 
> No it doesn't.  The nature of computing today is such that the
> distinction is lost because most so-called privileged processes are
> running either on single user machines where the user is the
> administrator, or on servers where this sort of thing is coordinated.

On the platforms that require admin rights to bind to ports less then 1024, it certainly matters. A user running such an app somehow needs to know to run it with root privileges. These platforms are not rare.

So even if we removed the boundary and said that the registered ports go from 1-49151, we would *still* need to treat the 1-1024 range differently. Handing out ports < 1024 to arbitrary requests will cause issues, when such apps gets deployed on platforms that require admin rights to bind to them. 

I agree that the distinction didn't make sense and doesn't make sense, but enough platforms act differently depending on what range your port falls into that we can't simply pretend the ranges are identical. They're not. Even if we don't like it.

So the iana-ports document does what at least the authors considered to be the practical way forward: the 0-1023 range requires "IETF Review" or "IESG Approval". Effectively, this means that you cannot get those ports anymore without the IETF OK'ing it. Essentially, this means we're moving everyone into the 1024-49151 range.

Do I believe that the IETF should make a statement that implementations should stop requiring admin rights for the 0-1023 range? Sure. But the iana-ports document is not the place for that statement.

Lars