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

[Joe Touch <[e-mail]>]

Hi, Jari,

Notes below...

Joe

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.

---