Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 26 October 2009 10:58 UTC

Return-Path: <iljitsch@muada.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 44C713A6A51 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 sCdMo2yEOp67 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:57:59 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 39BAF3A694E for <behave@ietf.org>; Mon, 26 Oct 2009 03:57:59 -0700 (PDT)
Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9QAvYWK030306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2009 11:57:34 +0100 (CET) (envelope-from iljitsch@muada.com)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <C70AC808.6944%rpenno@juniper.net>
Date: Mon, 26 Oct 2009 11:58:02 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com>
References: <C70AC808.6944%rpenno@juniper.net>
To: Reinaldo Penno <rpenno@juniper.net>
X-Mailer: Apple Mail (2.1076)
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.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: Mon, 26 Oct 2009 10:58:00 -0000

On 26 okt 2009, at 11:29, Reinaldo Penno wrote:

> I feel that NAT64 should look and feel in terms of behavior  
> (forwarding,
> control & security) as closely as NAT44 as possible in order to be  
> deployed
> successfully.

No. A traditional NAT44 sits on an internal/external boundary, a place  
where you would naturally want to apply security policy. However, this  
is not the case for a NAT64, which sits more towards the middle of the  
network. (Same for an ISP-operated NAT44.) It makes no sense to import  
NAT44 baggage into NAT64. Also, BEHAVE has been writing up what NAT44s  
actually do, while for NAT64 we're specifying what we WANT them to do,  
which is a rather different approach.

> Are you suggesting  all those security considerations should be  
> removed from
> NAT64 to another document and/or deprecated in NAT44 documents?

Yes, I believe some of the text quoted earlier would best be removed.  
Obviously that doesn't mean a NAT64 document shouldn't have any  
security considerations, just that firewalling should be kept out of  
the NAT64 document.