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.
---
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf