Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Joe Touch <touch@isi.edu> Wed, 13 February 2013 22:25 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F9821E803D for <int-area@ietfa.amsl.com>; Wed, 13 Feb 2013 14:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.82
X-Spam-Level:
X-Spam-Status: No, score=-102.82 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0VKVTSq8kfm for <int-area@ietfa.amsl.com>; Wed, 13 Feb 2013 14:25:20 -0800 (PST)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15411E80A3 for <int-area@ietf.org>; Wed, 13 Feb 2013 14:25:17 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1DMOxit017429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 14:24:59 -0800 (PST)
Message-ID: <511C12B5.5080001@isi.edu>
Date: Wed, 13 Feb 2013 14:24:53 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com>
In-Reply-To: <51198814.1060809@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: int-area@ietf.org, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org
Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis
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: Wed, 13 Feb 2013 22:25:20 -0000

On 2/11/2013 4:08 PM, Suresh Krishnan wrote:
> Hi Brian,
>    Thanks for the review. I wanted to clarify three points that you
> raised and I will ask the authors take care of the rest.
>
> On 02/11/2013 04:11 PM, Brian Haberman wrote:
>> 7. In Section 4.1.2, it would be good to describe any issues that the
>> approach has with the original use of the Identification field for
>> fragmentation reassembly.  If a middlebox changes the ID field, weird
>> things can/will happen if those packets are fragmented somewhere.
>
> Agree. I think this is precisely the reason that the mechanism for
> putting the HOST_ID in the IP-ID is a non-starter.

It happens if the packet is fragmented before the middlebox (reusing the 
HOST_ID will destroy the reassembly if any fragment groups are 
interleaved), or after (if there are multiple paths and not all 
fragments go through the middlebox.

It also violates RFC6864 if the packets are already fragmented when they 
go through the middlebox translation.

Joe