Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

Cullen Jennings <fluffy@cisco.com> Tue, 01 February 2011 17:16 UTC

Return-Path: <fluffy@cisco.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 A33A93A6E7F; Tue, 1 Feb 2011 09:16:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.588
X-Spam-Level:
X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zkusBUE52NnB; Tue, 1 Feb 2011 09:16:15 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 79EE63A6CC7; Tue, 1 Feb 2011 09:15:59 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANrOR02rRN+J/2dsb2JhbAClB3OhU5shAoVRBIUThxA
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 01 Feb 2011 17:19:16 +0000
Received: from sjc-vpn5-165.cisco.com (sjc-vpn5-165.cisco.com [10.21.88.165]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p11HJ6hF004674; Tue, 1 Feb 2011 17:19:16 GMT
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4D47DCF2.1000200@ericsson.com>
Date: Tue, 01 Feb 2011 12:19:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <11676222-268E-4084-BF81-F49A5C0300D8@cisco.com>
References: <20110118212603.5733.34489.idtracker@localhost> <B88A8A82-9C4A-40AC-89AF-F177260760F7@cisco.com> <ECA80A72-4E72-44D2-B40E-C90D7197E8C5@nokia.com> <4D421795.70505@isi.edu> <EFADE5D0-BB33-4418-B743-DFEC11B12740@cisco.com> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <B1E38EDF-E78E-47E2-B9A9-D7320A908217@nokia.com> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <F2152494-8C79-4A0F-951F-B3DB1D274A61@cisco.com> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1082)
Cc: IESG IESG <iesg@ietf.org>, IETF discussion list <ietf@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, 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: Tue, 01 Feb 2011 17:16:16 -0000

inline 

On Feb 1, 2011, at 5:14 , Magnus Westerlund wrote:

> Cullen Jennings skrev 2011-01-31 18:44:
> >
> > Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that.
> 
> Well, frankly I don't know. I think it is something that can be avoided
> going forward in many use cases, but not all. Simply by thinking of this
> issue in the design phase. In addition there is clearly other solutions
> there other considerations, like NAT traversal has said, yes
> multiplexing is a must, thus live with even higher complexity costs.
> 
> The issue I have a problem with is that is we say on general basis that
> due to negotiation of security protocols we are allowed to use different
> ports for negotiation or simply usage of it. Then why is that different
> from different versions of the protocol, or feature support. What is the
> difference for a security protocol compared to these other issues?

I've provided reason why I think this is needed for security in previous email on this thread. I'm not arguing you need more ports for versions or feature support - I don't think you do.

> What I am worried here is that we will see an increased port consumption
> rather than a decreased one. At the current run rate I think the
> estimate is 50 years+ before run out. That is something that I am
> reasonably comfortable, but if the consumption rate increases four
> times, then I am suddenly not comfortable. So I am pretty certain that
> we need to aim at lowering the consumption rather than raising it.
> 

I'm far more worried about people just using ports without registering them than I am about running out. Keep in mind the allocation policy is more or less anyone can get one port for just about anything so if we are really worried about running out, we would change that. Most protocols will not need or request two ports.

> As I see it there are only one way of doing it.
> 
> - State clearly that you really need to do everything reasonable so that
> your application is only for one port.

"Reasonable" here is the problem. I don't want the expert review to tell me a second port for security is not reasonable for cases where latency is a relevant. 

> - Be reasonably tough from the expert reviewer to ensure that applicants
> has done this.

Again - I want to be able to register ports for proprietary protocols without disclosing the details of the proprietary algorithm

> 
> And from that perspective I don't think security is special in anyway.

> It is only one of several things that could potentially require
> additional registered ports. Yes security is important, but as
> previously discussed it doesn't appear that the actual level of security
> provided is different if you are forced to use one port or two. It might
> affect the ease of implementation and deployment of security, which is
> another aspect of impact.

It's not just an "ease" of anything - it's the real time performance of the resulting system that is an issue. 

> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html