Re: [Softwires] The port mapping issue

Ole Troan <otroan@employees.org> Tue, 02 April 2013 01:18 UTC

Return-Path: <otroan@employees.org>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFED11E8126 for <softwires@ietfa.amsl.com>; Mon, 1 Apr 2013 18:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-h3N6MqAzud for <softwires@ietfa.amsl.com>; Mon, 1 Apr 2013 18:18:19 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 817CE11E811A for <softwires@ietf.org>; Mon, 1 Apr 2013 18:18:19 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id D6C7A5ECB; Mon, 1 Apr 2013 18:18:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=selector1; bh=k0OeGgdvSPMAQhN4ttnL5x5uInQ=; b=MPtdq7bBJ7KRt/7 xr5xqx4P4h2ZKzHdLbyd3iBUjYcLsAdmdbbR1uU6BzkfBMK0wsjm3UHS7/jGkNR1 /SUKaNWFNdbv7sQzOs63sA7aDtqG6+HltWScGB9J8fj7T0LZ6BZwgar33Y+ZvUge E/lZA5FFbd1B9BGXpEcIqgvJgrfU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; q=dns; s=selector1; b=DxHGF BRPYId28DEzIRNaf1Oga8o5fGWcj12YqSvtOuRPM2h6e2lEjVkbqAyhVP/fxedga QpIwux328t65rzx8nfseep+QUCAWg9L0jD+cX5ZXEQrD3UKFEmiaXksYOHx6/Ct9 kN3NBzWeerwiE81V7Nztg+w2fuN+7AfMwug8vA=
Received: from [172.16.101.103] (unknown [211.120.232.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 8ACC35EC1; Mon, 1 Apr 2013 18:18:18 -0700 (PDT)
References: <51512618.8070704@ericsson.com> <51531757.8000707@gmail.com> <5D7E58A0-C125-49BB-8609-5F650E2DCB01@cisco.com> <8B19A21F-21F0-4A97-87E4-22D3E183AE77@cisco.com> <FB82A3E5-45A1-4E85-8FD5-9C300C6AC5AB@cisco.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <FB82A3E5-45A1-4E85-8FD5-9C300C6AC5AB@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FDAD685-BFCA-47ED-8479-0AB6B31B9FED@employees.org>
X-Mailer: iPhone Mail (10B329)
From: Ole Troan <otroan@employees.org>
Date: Tue, 02 Apr 2013 10:18:15 +0900
To: Dan Wing <dwing@cisco.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, "Ole Troan (otroan)" <otroan@cisco.com>
Subject: Re: [Softwires] The port mapping issue
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 01:18:20 -0000

Dan,

>> 
>>>> The meeting minutes record a disagreement over what port mapping algorithm to use. This affects both MAP-E and LW 4over6. As I understand it:
>>>> 
>>>> - either of these two technologies will work with either contiguous ports or ports scattered according to the GMA algorithm
>>>> 
>>>> - the real objection to GMA comes from Alain Durand, who wants to set up simple min-port, max-port filters on his network equipment.
>>>> 
>>>> 
>>>> We all agree that port scattering offers negligible security advantage.
>>> 
>>> Port scattering, using GMA, provides tiny security advantage.  An attacker can determine the Generalized Modulus Algorithm, by causing a victim to open a bunch of TCP connections.  One way an attacker can cause a bunch of TCP connections to be opened is by sending an email with a bunch of <img src> tags to servers where the attacker can observe the TCP source ports for the connections.  Another way is to do the same with a web page.  GMA is a good amount of engineering and confusion for little gain, but the *appearance* of a gain because to a person the port numbers will appear random.  On other words, a false sense of security.  Port numbers are being used in courts of law and explaining GMA to the lay person will be complex.  I believe it is an unnecessary complexity.
>> 
>> Can you please read the latest draft?
>> What exactly is complex and confusing?
> 
> Non-contiguous ports are more confusing than contiguous ports, especially to people that don't understand binary math.  IP stacks used to allow non-contiguous 1's in subnet masks which were cute, but caused confusion with the humans.  (and some stacks couldn't cope well, but that is another topic.)  I worry about the humans being confused with the binary math.
> 
> 
>> GMA aka "port prefix" was not designed for scattering ports, that's a side effect. The requirement leading to that effect is, independence of end user ipv6 prefix. I.e avoid having to reserve a specific ipv6 prefix from assignment.
> 
> I agree the requirement is something we need.
> 
> Appendix B of draft-ietf-softwire-map-05.txt (March 18, I presume 'the latest') mentions the port scattering as an extreme case, which the algorithm supports.  Can we remove that support?

Arguing over perceived complexity is always going to be subjective. 

The main text (section 5) was rewritten to give a simpler and hopefully more understandable explanation than appendix B. 

To reiterate the reasoning:

Requirements:
1. Exclude the system ports
2. No dependency on end user ipv6 prefix. 
3. Fair distribution of ports among the sharers of the ipv4 address

The simplest port range representation I can think of is a 'port prefix', which is just like an address prefix. E.g you get a /8 of ports. (256). That representation does not exclude the system ports though. Remi's insight was that if you made it a 'port infix' (right shifted by 6) and require the msb bits to be larger than 0 you achieve all of the requirements above. Why 6? Because 2^(16-6) = 1024. So all sharees of that range excludes any port below 1024 and the ports they 'loose' from the range equal 1024/sharing ratio.

The side effect of the infix is scattered port ranges. 

 I believe the answer to your question is no. (But I cannot prove that there aren't other representations that do not fulfill the requirements and only do contiguous ports.) 

Cheers,
Ole