Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-ports-02
Fernando Gont <fernando@gont.com.ar> Mon, 05 October 2009 09:13 UTC
Return-Path: <fernando.gont.netbook@gmail.com>
X-Original-To: port-srv-reg@core3.amsl.com
Delivered-To: port-srv-reg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FE428C159; Mon, 5 Oct 2009 02:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 hp0fg7NM4aoG; Mon, 5 Oct 2009 02:13:31 -0700 (PDT)
Received: from mail-vw0-f117.google.com (mail-vw0-f117.google.com [209.85.212.117]) by core3.amsl.com (Postfix) with ESMTP id EEC8728C169; Mon, 5 Oct 2009 02:13:30 -0700 (PDT)
Received: by vws15 with SMTP id 15so35353vws.5 for <multiple recipients>; Mon, 05 Oct 2009 02:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fiIarVzNpPQiYg4Kvw+Eq3qOBXxRGtcHucbBa/66DEc=; b=EZbPMyfVf3sSr8hkU1OSm3g2XyEpBrqsvWmdcKYaKB0dfSZKDc+ghsxje72EeYULnF P4GiVFnzJYvXZES5+8k5243bbxc2HuhXPXTYtAjkHKo0io12zFHRUR3DGr3MPMCgBMwM SXbZZNoQ36V7ObIbGpdTEfLoUXalYUoGBu8Fg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rAm/SukMKVBKw/k0kVlbHYcw67Zqha0gkdnWBYHg5TqVSu2tiYD0Q58eI61Op4KMLp ZG1E31DuPpBkSuog5mnTbTnMCiZEkP4f+L2DgqUXfT6oUqmkSaNKxivRa9xmAzYcWHjU 1UdvJu+neavGxVvw89OWvQ29PtdLKrDI8HvO8=
MIME-Version: 1.0
Sender: fernando.gont.netbook@gmail.com
Received: by 10.220.107.103 with SMTP id a39mr9510484vcp.6.1254734100759; Mon, 05 Oct 2009 02:15:00 -0700 (PDT)
In-Reply-To: <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com>
References: <200909291410.QAA19651@TR-Sys.de> <7D5E249F-06D0-45DB-A63A-33303229F457@nokia.com>
Date: Mon, 05 Oct 2009 06:15:00 -0300
X-Google-Sender-Auth: 8617939776738471
Message-ID: <6468cc520910050215x9314627uf8c28b25a4ecd13d@mail.gmail.com>
From: Fernando Gont <fernando@gont.com.ar>
To: Lars Eggert <lars.eggert@nokia.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 05 Oct 2009 02:19:44 -0700
Cc: ah@tr-sys.de, tsvwg <tsvwg@ietf.org>, apps-discuss@ietf.org, draft-ietf-tsvwg-iana-ports@cabernet.tools.ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>, port-srv-reg@ietf.org
Subject: Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-ports-02
X-BeenThere: port-srv-reg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of updates to service name and transport protocol port registry <port-srv-reg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/port-srv-reg>
List-Post: <mailto:port-srv-reg@ietf.org>
List-Help: <mailto:port-srv-reg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2009 09:13:32 -0000
On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert <lars.eggert@nokia.com> wrote: >> The Port Number registry is heavily constrained by the 16-bit >> namespace available, with the additional pressure resulting >> from the security critical need for client port randomization >> to only assign as few as possible additional port numbers. > > Randomization doesn't come into play here, because it's used for the source > ports, whereas the registry is for destination ports. Ephemeral ports (and randomization) do come into play. See Section 10.2 of the d. ocument "Security Assessment of the Transmission Control Protocol (TCP)" (available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf) published by UK CPNI (or its IETF I-D counterpart draft-gont-tcp-security). This is an excerpt of the aforementioned document, for your convenience: ---- begin excerpt ---- 10.2. Active opens and binding sockets As discussed in Section 10.1, the “OPEN” command specified in Section 3.8 of RFC 793 [Postel, 1981c] can be used to perform active opens. In case of active opens, the parameter “local port” will contain a so-called “ephemeral port”. While the only requirement for such an ephemeral port is that the resulting connection-id is unique, port numbers that are currently in use by a TCP in the LISTEN state should not be allowed for use as ephemeral ports. If this rule is not complied, an attacker could potentially steal” an incoming connection to a local server application by issuing a connection request to the victim client at roughly the same time the client tries to connect to the victim server application. If the SYN segment corresponding to the attacker's connection request and the SYN segment corresponding to the victim client “cross each other in the network”, and provided the attacker is able to know or guess the ephemeral port used by the client, a TCP simultaneous open scenario would take place, and the incoming connection request sent by the client would be matched with the attacker's socket rather than with the victim server application's socket. As already noted, in order for this attack to succeed, the attacker should be able to guess or know (in advance) the ephemeral port selected by the victim client, and be able to know the right moment to issue a connection request to the victim client. While in many scenarios this may prove to be a difficult task, some factors such as an inadequate ephemeral port selection policy at the victim client could make this attack feasible. It should be noted that most applications based on popular implementations of TCP API (such as the Sockets API) perform “passive opens” in three steps. Firstly, the application obtains a file descriptor to be used for inter-process communication (e.g., by issuing a socket() call). Secondly, the application binds the file descriptor to a local TCP port number (e.g., by issuing a bind() call), thus creating a TCP in the fictional CLOSED state. Thirdly, the aforementioned TCP is put in the LISTEN state (e.g., by issuing a listen() call). As a result, with such an implementation of the TCP API, even if port numbers in use for TCPs in the LISTEN state were not allowed for use as ephemeral ports, there is a window of time between the second and the third steps in which an attacker could be allowed to select a port number that would be later used for listening to incoming connections. Therefore, these implementations of the TCP API should enforce a stricter requirement for the allocation of port numbers: port numbers that are in use by a TCP in the LISTEN or CLOSED states should not be allowed for allocation as ephemeral ports. An implementation might choose to relax the aforementioned restriction when the process or system user requesting allocation of such a port number is the same that the process or system user controlling the TCP in the CLOSED or LISTEN states with the same port number. ---- end excerpt ---- Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Fernando Gont
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Fernando Gont
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Iljitsch van Beijnum
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Fernando Gont
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Alfred Hönes
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Fernando Gont
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Fernando Gont
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Lars Eggert
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Fernando Gont
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Eliot Lear
- Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-… Joe Touch