Re: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt

Dave Thaler <dthaler@microsoft.com> Sun, 07 November 2010 02:36 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E30C3A6980 for <behave@core3.amsl.com>; Sat, 6 Nov 2010 19:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.682
X-Spam-Level:
X-Spam-Status: No, score=-110.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 td9IUf+Vzy0e for <behave@core3.amsl.com>; Sat, 6 Nov 2010 19:36:55 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9777428C105 for <behave@ietf.org>; Sat, 6 Nov 2010 19:36:55 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 6 Nov 2010 19:37:02 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.255.3; Sat, 6 Nov 2010 19:37:01 -0700
Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.9]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Sat, 6 Nov 2010 19:37:02 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: "'behave' (behave@ietf.org)" <behave@ietf.org>, "draft-ietf-behave-lsn-requirements@tools.ietf.org" <draft-ietf-behave-lsn-requirements@tools.ietf.org>
Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt
Thread-Index: AQHLbqdU6IvLNJdouk6aC6MHRHETx5NJgXuAgBvkuuA=
Date: Sun, 07 Nov 2010 02:36:59 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF65343694EA@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
References: <20101018093010.4476D3A6C58@core3.amsl.com> <20101020101329.77EB.68FF0486@nttv6.jp>
In-Reply-To: <20101020101329.77EB.68FF0486@nttv6.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2010 02:36:58 -0000

Some comments:

1) The title is misleading.  It should be something like "Requirements for Large Scale NATs",
    to make it clear that this isn't a generic requirements document for all NATs, just
    large scale ones, or perhaps more correctly, ones that serve multiple 
   organizations/subscribers.

2) After reading draft-cheng-behave-nat44-pre-allocated-ports-01, I think there's some
    key requirements missing discussion in the lsn-requirements draft.  These include:
    * Fairness among subscribers with respect to "valuable" ports like 80 and 443.
    * Allow sufficient randomization to mitigate some security threats against a particular
       subscriber, per the tsv ports document.
    * Allow over-subscription of ports if the administrator desires.  That is, allow possibility of
       subscriber using more than (# ports / # subscribers) ports as long as everyone doesn't
       try this.
    * Provide efficient (in terms of message and storage) logging of what subscriber was
       assigned what ports at what times.

3) Section 1 claims RFCs 4787, 5382, and 5508 were aimed at residential CPEs.  I don't
    agree with that, they're general.  That's why this document only have requirements that
    are in addition to those, for requirements that are unique to LSNs.   An example later
    in the document is that REQ-6 and REQ-7 state that support for 4787 and 5382 is just
    a SHOULD.  Why aren't they MUSTs?

4) Section 2 defines LSN as being between "CPE" and the public Internet.   This is problematic
    because LSNs can be used in cases where there's no "CPE" per se, and so the term CPE
    should really be removed from this document.   For example, in a mobile network, or in
    a hotspot provider (airports, etc.), or in large enterprise networks, etc., there might not
    be something that the term "CPE" would be appropriate for.   The point is to define the LSN
    without respect to "premise".

5) REQ-1 in section 3 has a related problem.   It is currently phrased in as allocating one
    external IP address to each *CPE*.  This should be to each *internal IP*, since it has no
    idea in general how many IPs the same CPE has, or which IPs correspond to the same CPE.

6) Regarding REQ-3e, why is this a requirement for TCP but not for UDP or ICMP?  In other words,
    if the *rate* of memory consumption matters (not just the total amount), then it seems like
    the rate would matter for mappings created for UDP.

7) Just about figure 2, it has "If" a LSN supports hairpinning.   Why isn't hairpinning support
    a MUST REQ?

8) Section 7 starts to describe a mechanism ("The following mechanisms can be used ...").
    I don't think that's appropriate in a requirements document.   Sections 7.1 and 7.2 should be
    deleted in my view.  Similarly section 8 has "two ways to solve this issue".  They should be
    replaced with text stating what the relevant REQ's are.

I have some additional editorial comments that I'll send later, but wanted to get the above
feedback out first.

-Dave

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
> Of Ikuhei.Yamagata
> Sent: Wednesday, October 20, 2010 9:19 AM
> To: behave@ietf.org
> Cc: shared@hir.jp
> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt
> 	
> Dear all,
> 
> We posted new behave WG, draft-ietf-behave-lsn-requirements.
> This draft changed from draft-nishitani-cgn, and some requirements changes.
> 
> Comments most welcomed!
> 
> Best wishes,
> ikuhei
> 
> On Mon, 18 Oct 2010 02:30:09 -0700 (PDT) Internet-Drafts@ietf.org wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Behavior Engineering for Hindrance Avoidance
> Working Group of the IETF.
> >
> >
> > 	Title           : Common requirements for IP address sharing schemes
> > 	Author(s)       : I. Yamagata, et al.
> > 	Filename        : draft-ietf-behave-lsn-requirements-00.txt
> > 	Pages           : 13
> > 	Date            : 2010-10-18
> >
> > This document defines common requirements of multiple types of Large
> > Scale Network Address Translation (NAT) that handles Unicast UDP, TCP
> > and ICMP.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements
> > -00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> 
> ----------------------------------------------
> Ikuhei Yamagata
> Innovative IP Architecture Center
> NTT Communications Corporation
> ikuhei@nttv6.jp
> phone:81-3-6733-8671(main)
>             50-3812-4704(direct)
> ----------------------------------------------
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave