Re: [Int-area] Some comments for 4rd

<c-sun@bb.softbank.co.jp> Fri, 22 April 2011 02:49 UTC

Return-Path: <c-sun@bb.softbank.co.jp>
X-Original-To: int-area@ietfc.amsl.com
Delivered-To: int-area@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1F2FE077C for <int-area@ietfc.amsl.com>; Thu, 21 Apr 2011 19:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.956
X-Spam-Level:
X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txd5WIiU5CiA for <int-area@ietfc.amsl.com>; Thu, 21 Apr 2011 19:49:15 -0700 (PDT)
Received: from bb.softbank.co.jp (m1.bb.softbank.co.jp [210.146.18.150]) by ietfc.amsl.com (Postfix) with ESMTP id 23852E077B for <int-area@ietf.org>; Thu, 21 Apr 2011 19:49:14 -0700 (PDT)
Received: from CI-EXHB-04.bb.local (10.241.1.5) by m1.bb.softbank.co.jp (210.146.18.150) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 22 Apr 2011 11:49:13 +0900
Received: from CI-EXMB-09V.bb.local ([fe80::15e:dbec:b8a2:731f]) by CI-EXHB-04.bb.local ([::1]) with mapi; Fri, 22 Apr 2011 11:49:13 +0900
From: c-sun@bb.softbank.co.jp
To: dwing@cisco.com, tena@huawei.com, int-area@ietf.org
Date: Fri, 22 Apr 2011 11:49:12 +0900
Thread-Topic: [Int-area] Some comments for 4rd
Thread-Index: Acv513EEgB0AidJaRV+R6cpHxz5MQgAWIj5wANQbB6AAJ1Rt4ACeRjQQ
Message-ID: <6CADC58598A4D249AD3B5026CE8CC33906D758ED@CI-EXMB-09V.bb.local>
References: <00ef01cbfa30$5eb5ad50$1c2107f0$@com> <6CADC58598A4D249AD3B5026CE8CC33906D758D5@CI-EXMB-09V.bb.local> <0c2301cbfe1f$2344e4f0$69ceaed0$@com>
In-Reply-To: <0c2301cbfe1f$2344e4f0$69ceaed0$@com>
Accept-Language: zh-CN, ja-JP
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: zh-CN, ja-JP
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Int-area] Some comments for 4rd
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 02:49:16 -0000

 
Hi, Dan

Thank you for your comments.
I will cite RFC6056 and try to reduce the discussion in section 5.

Chunfa 

> >5.       In section 5 of applicability draft
> >     "Shared address issues [I-D.ietf-intarea-shared-addressing-
> issues] describes a method for
> >  the random selection of TCP Sequence Number, that reduces the
> ability of attacker to correctly guess the 5-ruple."
> 
> >   Random selection of TCP Sequence Number is to prevent the attacker
> from guessing the next TCP SN, not the 5-tuple.
> 
> You are right. I will change it in the next version of draft.

I noticed the existing text in
http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#se
ction-5 says the client goes into TIME_WAIT ("It is important to realize that the TCP design makes it undesirable for clients to re-use ports while they remain in the TIME-WAIT state (typically 4 minutes after the connection has concluded).") -- however, that depends on the client doing the active close.  I see that http://tools.ietf.org/html/rfc6056#section-2.3 discusses what happens when the server does the active close:  the client doesn't go into TIME_WAIT.  The recommendation in draft-ietf-intarea-shared-addressing-issues appears to re-enforce the suggestion in the last sentence of http://tools.ietf.org/html/rfc6056#section-2.3, which says:

   A simple but inefficient approach to minimize the rate of collisions
   of instance-ids would be, e.g., in the case of TCP, for both
   endpoints of a TCP connection to keep state about recent connections
   (e.g., have both endpoints end up in the TIME-WAIT state).

perhaps you could cite RFC6056 and reduce the discussion in Section 5?