Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02

Joe Touch <touch@isi.edu> Wed, 02 February 2011 22:11 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C9D3A6C3A for <ietf@core3.amsl.com>; Wed, 2 Feb 2011 14:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.617
X-Spam-Level:
X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, 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 wy6c0+EIDXAo for <ietf@core3.amsl.com>; Wed, 2 Feb 2011 14:11:45 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 116013A6AF5 for <ietf@ietf.org>; Wed, 2 Feb 2011 14:11:44 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p12MEse2008012 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 14:14:54 -0800 (PST)
Message-ID: <4D49D75E.1010808@isi.edu>
Date: Wed, 02 Feb 2011 14:14:54 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <4D48B4EA.20503@isi.edu> <4D49D2C9.50508@necom830.hpcl.titech.ac.jp>
In-Reply-To: <4D49D2C9.50508@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p12MEse2008012
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2011 22:11:49 -0000

On 2/2/2011 1:55 PM, Masataka Ohta wrote:
> Joe Touch wrote:
>
>>> 9. ICMP
>>>
>>> ICMP does not carry any port information and is consequently
>>> problematic for address sharing mechanisms.
>>
>> ICMP messages are specifically intended to include enough of the
>> transport header to enable port demuxing at the end receiver.
>
> I think it says ICMP information messages such as echo request
> do not have port numbers.

I quoted the start of the section. The first sentence, without further 
qualification, is inaccurate, IMO.

ICMP messages do not themselves have port numbers, but they are intended 
to *carry* port numbers of the messages that caused their generation (if 
they report errors).

> However, ID and sequence number field of echo request can be
> used (overridden) as source and destination port numbers,
> respectively.

This is relevant to the generation of new ICMPs that are not the result 
of errors - e.g., echo request. The section is written so generally as 
to include ICMPs that are responses to errors too, typically as 
generated by packet arrivals.

> As the fields are copied as is from echo request to echo reply,
> ID and sequence number field of echo request must be
> used as destination and source (reversed) port numbers,
> respectively.
>
> It's implemented for end to end NAT and is working with "ping"
> and "traceroute".
>
>>> 11. Fragmentation
>>>
>>> When a packet is fragmented, transport-layer port information (either
>>> UDP or TCP) is only present in the first fragment. Subsequent
>>> fragments will not carry the port information and so will require
>>> special handling.
>>
>> ?INT? The ID will be incorrect too; it may not be unique as required
>> when viewed from the outside.
>
> Port based redirection MUST be done after fragmentation reassembly.
>
> That's all and is no special.

IMO, any device that initiates packets MUST verify that the IDs emitted 
follow spec. Once a packet's address(es) are rewritten, the NAT is 
responsible for ensuring that the IDs are unique across the 
src/dst/proto triple.

I'm not aware of NATs that do this; they typically copy the ID field, 
and this can easily cause reassembly errors later - even if the packet 
is reassembled at the NAT itself.

See draft-ietf-intarea-ipv4-id-update for more a discussion of this 
issue and the proposed requirements to address it.

Joe