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

Joe Touch <> Wed, 02 February 2011 22:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E84633A6E1E; Wed, 2 Feb 2011 14:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.617
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wRnvd+zAJ8vx; Wed, 2 Feb 2011 14:01:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 01F5C3A6E1A; Wed, 2 Feb 2011 14:01:32 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id p12M4LL9006188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 14:04:21 -0800 (PST)
Message-ID: <>
Date: Wed, 02 Feb 2011 14:04:21 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Jari Arkko <>
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p12M4LL9006188
X-ISI-4-69-MailScanner: Found to be clean
Cc: "" <>,, IETF discussion list <>, TSV Dir <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Feb 2011 22:01:34 -0000

Hi, Jari,

Notes below...


On 2/1/2011 10:10 PM, Jari Arkko wrote:
>> - parallel connections
>> i.e., that assume that a single IP address used
>> for multiple connections implies a single machine,
>> as with striping, multipath, or systems that use
>> multiple concurrent connections for different services
>> (somewhat related to load balancing in sec 16, but not necessarily)
> Why is this an issue? I thought that many of these mechanisms explicitly
> signal that a new connection is going to be established. Are there
> systems that assume that two independent connections are to the same
> machine, if they come from the same IP address? And isn't that
> assumption already broken by existing NATs?

Yes, and yes. The doc currently includes other such issues, and this 
seems worth including too.

>> - serial connections
>> i.e., that assume that returning to a given IP address returns to the
>> same physical host,
>> as with stateful transactions; this may also affect
>> cookie-based systems, such as TCP-CT, TCP with SYN
>> cookies, etc.
> OK. Interesting.

FWIW, this is like banking or other transaction systems, that use 
back-end data consistency or 'intelligent' routing to try to avoid 
sending series of connections to different places.

>> - address or DNS-name-based signatures
>> as in some X.509 signatures
> Why would DNS-name based certificates be an issue? You can still have
> multiple names per an IP address.

I might sign something with my hostname which isn't in the list of names 
for the shared address. I.e., this is a case where reverse DNS is the 
issue, but the impact is to a secondary system (X.509).

>> ...
>>> 7. Geo-location and Geo-proximity
>> ?INT? This section is, IMO, odd; IP address never meant physical
>> location anyway, and tunnels obviate that meaning regardless of the
>> impact of NATs or other sharing techniques.
> Perhaps it is an odd practice, but geo-location by IP is a very
> widespread technique, and address sharing does impact it. I do think it
> should be covered by the document.

It should be, but it might be useful to note that geolocation by IP is a 
hueristic at best, and already challenged by other deployed capabilities 
(e.g., tunnels). The point is that the ability to do geolocation isn't 
part of IP, and isn't something that NAT/sharing breaks more than it's 
basically already broken, IMO.

I.e., it's useful to not imply that this issue will be fixed by avoiding 
NAT/sharing per se.

>>> 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.
> Yes. Though this seems to be an issue in existing NATs already. (But do
> the existing BEHAVE RFCs say something about IPID allocation/change by
> NATs?)

Yes, and not sure. Fragmentation causes multiple issues, not just the 
unknown port one.