Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Joe Touch wrote: 9. ICMP I quoted the start of the section. The first sentence, without further qualification, is inaccurate, IMO. Anyway, most of the discussion in the section is inapplicable to end to end NAT where public source addresses are used even within private networks. 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). FYI, traceroute both with UDP or ICMP ECHO is working to/from /between private network behind end to end gateway is working. 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. IC. We can rely on random id and transport checksum, then. See draft-ietf-intarea-ipv4-id-update for more a discussion of this issue and the proposed requirements to address it. It should be noted that packet smaller than 69B is also atomic. The problem of the draft (and IPv6) is that it depends on PMTUD. PMTUD just does not work. Worse, PMTUD is inefficient. That is, that PMTUD periodically sends oversized packets means PMTUD overloads routers, just as IPv4 fragmentation overloads routers. If we write a draft on IPv6 issues, it should contain a lot more and a lot more serious issues than those of shared addressing. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 2/3/2011 1:48 AM, Masataka Ohta wrote: Joe Touch wrote: 9. ICMP 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). FYI, traceroute both with UDP or ICMP ECHO is working to/from /between private network behind end to end gateway is working. Understood, but my issue is that ICMP is more than just ICMP echo; many other messages are the result of sending a regular packet (as with traceroute), and those are intended to include both the address and port of the packet that causes the ICMP. 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. IC. We can rely on random id and transport checksum, then. Transport checksum works only if the entire transport packet is included in the ICMP response, and should not be relied on because it's only a SHOULD to include the entire packet (and that entire packet wouldn't fit if it was already at the path MTU anyway - there wouldn't be room for the ICMP IP header or its additional fields). See draft-ietf-intarea-ipv4-id-update for more a discussion of this issue and the proposed requirements to address it. It should be noted that packet smaller than 69B is also atomic. Packet size is not a consideration in whether a packet is atomic. Packets under 69B must be able to be carried without fragmentation by a link as per RFC791, but there's nothing in RFC791 that prohibits such packets from being fragmented anyway. The only trick would be that the node that did such fragmentation would need to know when to stop - so that a packet with a max IP header and at least one 8-octet fragment could eventually get through. But nothing in RFC791 requires that this be the original packet. The problem of the draft (and IPv6) is that it depends on PMTUD. Please explain how and where. PMUTD isn't even discussed or cited. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Joe Touch wrote:
9. ICMP
FYI, traceroute both with UDP or ICMP ECHO is working to/from
/between private network behind end to end gateway is working.
Understood, but my issue is that ICMP is more than just ICMP echo;
many other messages are the result of sending a regular packet (as with
traceroute), and those are intended to include both the address and port
of the packet that causes the ICMP.
Yes, ICMP time exceeded including UDP can be routed and is actually
working.
IC. We can rely on random id and transport checksum, then.
Transport checksum works only if the entire transport packet is included
in the ICMP response,
ICMP? I'm afraid the only ICMP possibly affected by reassembly
is port unreachable. Moreover, as long as destination port number
is correct, proper response can be returned. Purely theoretically,
wrong reassembly of IPv6 (or IPv4 with fragmented ICMP error) can
make the destination port number wrong. Still, as the source port
number is assured to be in the same fragment as the destination
port number, the port unreachable message itself is correct.
You should better worry about the theoretical possibility that
port numbers are not included in the first fragment of IPv6
packet (because of lengthy optional headers).
It should be noted that packet smaller than 69B is also atomic.
Packet size is not a consideration in whether a packet is atomic.
Packets under 69B must be able to be carried without fragmentation by a
link as per RFC791, but there's nothing in RFC791 that prohibits such
packets from being fragmented anyway.
RFC791 specifies fragmentation occur only when necessary:
The internet modules use fields in the internet header to fragment and
reassemble internet datagrams when necessary for transmission through
small packet networks.
and necessary is defined as:
Fragmentation of an internet datagram is necessary when it
originates in a local net that allows a large packet size and must
traverse a local net that limits packets to a smaller size to reach
its destination.
NetBSD, for example, assumes so:
if (m-m_pkthdr.len IP_MINFRAGSIZE) {
ip-ip_id = 0;
thanks to IPv6, we can safely assume not only IPv6, but also IPv4,
packets smaller than 1281B is atomic.
BTW, note that atomic packets may be fragmented within a tunnel as
is specified in RFC2473, which is used for IPv6 mobility.
But nothing in RFC791 requires that this be the original packet.
That a fragment can be 28B long does not mean 68B packet may be
fragmented unnecessarily. Note also a suggestion in RFC791:
An alternative might produce less
than the maximum size datagrams. For example, one could implement
a fragmentation procedure that repeatly divided large datagrams in
half until the resulting fragments were less than the maximum
transmission unit size.
which is seemingly ignored but should be useful today with nested
tunneling.
The problem of the draft (and IPv6) is that it depends on PMTUD.
Please explain how and where. PMUTD isn't even discussed or cited.
You can't safely send an IPv4 (with DF=1) or IPv6 packet larger
than 1280B unless you know path MTU.
It's an issue of IPv6, not specific to the draft.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Fernando Gont wrote: The fact that geo-location was not considered in the IP design, is irrelevant. As noted, IP wasn't meant for production, either. As the address sharing occurs only at the edge, it is quite unlikely that geo location approximation breaks. You can assume hosts sharing an address have the same location, much more safely than assume hosts in a /24 address range have the same location. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 01/02/2011 10:35 p.m., Joe Touch wrote: Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4 address pool and thereby mitigate the need for address sharing mechanisms that give rise to the issues identified herein. ?? This sentence is misleading. Clearly address sharing eases pressure too, but has caveats. It should be revised to be more clear about the options available. +1 ... 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. Agreed. But geo-location is nevertheless widely ued for marketing purposes. 13.4. Port Randomisation ... It should be noted that guessing the port information may not be sufficient to carry out a successful blind attack. The exact TCP Sequence Number (SN) should also be known. There are data injection attacks that are possible even without knowing the exact SN. draft-ietf-tcpm-tcp-security may be of use here. Further, port randomization is just one way to protect a connection (another includes timestamp verification, as noted in RFC4953). RFC4953 is a little bit vague in this respect. It talks about an accepted window. However, as far as the current specs are concerned, the accepted window is half the timestamps space: i.e., you need to forge, at most, two different timestamps value. It also mentions that timestamps may be easily predictable. However, this does not need to be the case (see e.g., draft-gont-timestamps-generation) Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Joe, Thanks for your review. A couple of comments inline: Transport issues include: - refers to Well Known ports Throughout this document, this usually refers to the entire Assigned range, i.e., Well-known (i.e., System) as well as Registered (i.e., User) ports. It would be preferable to refer to them as Assigned ports, and include (both System and User). The term Registered should, FWIW, be avoided as it is ambiguous (since both User and System ports are registered with IANA). OK - omits numerous transport issues from the table Such issues include, but may not be limited to: - port handoff this is included in section 6, but not in the table and sec 6 should call out specific protocols affected, e.g., FTP, among others) - port discovery (using a UDP port to discover a service available on a corresponding TCP port, either through broadcast, multicast, or unicast) this is common, and not discussed anywhere see -disc in the IANA ports listing (that suffix has been in use recently, and helps highlight how common the practice is) - service discovery through the DNS (e.g., SRV records) mentioned in 5.2.2, but not here OK - 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? - 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. - TCP state mechanisms e.g., that might allow a connection that should have been in TIME-WAIT (this is discussed in Sec 5, but not listed as an issue) OK - 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. - omits some network issues from the table This is in Sec 11, but missing from the table. See the NAT discussion in draft-ietf-intarea-ipv4-id-update for a related discussion. There appear to be more issues here than just the lack of port numbers. --- ... Issues with IP Address Sharing draft-ietf-intarea-shared-addressing-issues-02 Abstract The completion of IPv4 address allocations from IANA and the RIRs is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues and this memo identifies those common to all such address sharing approaches. Solution- specific discussions are out of scope. ?? The abstract is a bit vague. It would be useful to summarize some of the issues of note. ... 1. Introduction ... Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4 address pool and thereby mitigate the need for address sharing mechanisms that give rise to the issues identified herein. ?? This sentence is misleading. Clearly address sharing eases pressure too, but has caveats. It should be revised to be more clear about the options available. ... 2. Shared Addressing Solutions This section should define address sharing. It's implied, and two variants given (1:N NAT, and M:N pooled sharing), but that should be made very direct and clear. ... In Figure 1 we have also tried to indicate (with 'xx') where issues are newly created in addition to what could be expected from the introduction of a traditional NAT device. Issues marked with a single 'x' are already present today in the case of typical CPE NAT, however they can be expected to be more severe and widespread in the case of large-scale address sharing. ?? The notation description could be more clear, e.g. (presuming the description is correct): ?? In this figure, x indicates issues already present with a NAT, and xx are for those further issues introduced by pooled sharing.
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Hi, Fernando, On 2/2/2011 12:03 AM, Fernando Gont wrote: On 01/02/2011 10:35 p.m., Joe Touch wrote: ... ... 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. Agreed. But geo-location is nevertheless widely used for marketing purposes. Agreed, but whether it works now is arbitrary; it's not a design consideration of the protocols. At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. 13.4. Port Randomisation ... It should be noted that guessing the port information may not be sufficient to carry out a successful blind attack. The exact TCP Sequence Number (SN) should also be known. There are data injection attacks that are possible even without knowing the exact SN. draft-ietf-tcpm-tcp-security may be of use here. rfc5961 is already published and describes the issue in specific, and may be more useful as a reference for this. Further, port randomization is just one way to protect a connection (another includes timestamp verification, as noted in RFC4953). RFC4953 is a little bit vague in this respect. Yes, but it does refer to the issue. The point is just that the current doc focuses on one way, there are others, and that's worth noting IMO. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
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. However, ID and sequence number field of echo request can be used (overridden) as source and destination port numbers, respectively. 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. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 02/02/2011 02:38 p.m., Joe Touch wrote: ?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. Agreed. But geo-location is nevertheless widely used for marketing purposes. Agreed, but whether it works now is arbitrary; it's not a design consideration of the protocols. Well, the protocols were not designed for production networks, either. FWIW, geo-location is currently used, and it would be affected by increased used of NATs. At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. Tunnels need not break geo-location. -- They do not masquerade the source address. Or am I missing something? And, FWIW, I agree that usually lots of breakage is attributed to NATs, where the brokeness is really somewhere else (e.g., app protocols passing IP addresses). 13.4. Port Randomisation ... It should be noted that guessing the port information may not be sufficient to carry out a successful blind attack. The exact TCP Sequence Number (SN) should also be known. There are data injection attacks that are possible even without knowing the exact SN. draft-ietf-tcpm-tcp-security may be of use here. rfc5961 is already published and describes the issue in specific, and may be more useful as a reference for this. I disagree. It discusses only TCP-based attacks (there are many other vectors). If you want an alternative published reference, here it is: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf However, it's up to the authors to include this or other references -- I just noted the tcp assessment doc for completeness sake. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 2/2/2011 5:04 PM, Fernando Gont wrote: ... At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. Tunnels need not break geo-location. -- They do not masquerade the source address. Or am I missing something? When I tunnel using an ISI address, whomever sees my address thinks I'm in California. Except that there's an ISI office in Virginia too. And if I'm VPN'd in, the tunnel makes me have an ISI IP address regardless of where I actually am. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 02/02/2011 10:08 p.m., Joe Touch wrote: On 2/2/2011 5:04 PM, Fernando Gont wrote: ... At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. Tunnels need not break geo-location. -- They do not masquerade the source address. Or am I missing something? When I tunnel using an ISI address, whomever sees my address thinks I'm in California. [..] Ok.. I see. I was thinking about tunnels in the infrastructure. -- those are transparent in this respect. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 02/02/2011 10:24 p.m., Fernando Gont wrote: On 2/2/2011 5:04 PM, Fernando Gont wrote: ... At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. Tunnels need not break geo-location. -- They do not masquerade the source address. Or am I missing something? When I tunnel using an ISI address, whomever sees my address thinks I'm in California. [..] And one might argue that, in this type of scenario, this breakeage of geo-location might, in some cases, be desirable. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 2/2/2011 5:30 PM, Fernando Gont wrote: On 02/02/2011 10:24 p.m., Fernando Gont wrote: On 2/2/2011 5:04 PM, Fernando Gont wrote: ... At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. Tunnels need not break geo-location. -- They do not masquerade the source address. Or am I missing something? When I tunnel using an ISI address, whomever sees my address thinks I'm in California. [..] And one might argue that, in this type of scenario, this breakeage of geo-location might, in some cases, be desirable. It can't break if it was never intended to work. Anyone who thinks that IP address = location is as incorrect as those who assume area code = location these days. I.e., the overall assumption was never true. The fact is that it *sometimes* works, that's all. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
On 2/2/2011 5:24 PM, Fernando Gont wrote: On 02/02/2011 10:08 p.m., Joe Touch wrote: On 2/2/2011 5:04 PM, Fernando Gont wrote: ... At the least, it's worth noting that geolocation is already broken by tunnels, and that IP addressing does not ensure geographic proximity before attributing breakage on NATs or other sharing. Tunnels need not break geo-location. -- They do not masquerade the source address. Or am I missing something? When I tunnel using an ISI address, whomever sees my address thinks I'm in California. [..] Ok.. I see. I was thinking about tunnels in the infrastructure. -- those are transparent in this respect. Yes. It's tunnels at the endpoints I'm using as an example here. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Joe, On 02/02/2011 10:49 p.m., Joe Touch wrote: When I tunnel using an ISI address, whomever sees my address thinks I'm in California. [..] And one might argue that, in this type of scenario, this breakeage of geo-location might, in some cases, be desirable. It can't break if it was never intended to work. I've been attended presentations in which people have argued that this geo-location thing (i.e., multiple-layers of NATs breaking it) is yet another motivation for v6. -- I don't buy it (nor do I buy much of the NAT is evil and similar stuff). But this thing is being used, and if multiple layers of NAT will break it (or, will prevent it to work the way it used to, if you prefer), it should be noted. The fact that geo-location was not considered in the IP design, is irrelevant. As noted, IP wasn't meant for production, either. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document describes the issues with IP address sharing approaches, independent of approach. The document does include a number of application issues, many of which originate from transport protocol problems, as well as a few specific transport issues. There are a few missing transport issues that should be addressed prior to final publication, as noted below. Overall, the document does discuss some such issues in various places, but the table should include these issues, and the issue discussion should be expanded to include some issues not currently addressed. Some of these changes are substantive, however, and I recommend that the changes be discussed in the transport WG (e.g. TSVWG, ts...@ietf.org) before proceeding with publication of this document. The note below includes the significant transport issues, as well as additional comments interspersed in a copy of the text as well. Some are editorial (??) and should not impede doc. progress. There are a few issues labeled ?INT? that are Internet-area (IP), not transport issues, but they would be very useful to also treat as substantive rather than editorial. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Joe -- Transport issues include: - refers to Well Known ports Throughout this document, this usually refers to the entire Assigned range, i.e., Well-known (i.e., System) as well as Registered (i.e., User) ports. It would be preferable to refer to them as Assigned ports, and include (both System and User). The term Registered should, FWIW, be avoided as it is ambiguous (since both User and System ports are registered with IANA). - omits numerous transport issues from the table Such issues include, but may not be limited to: - port handoff this is included in section 6, but not in the table and sec 6 should call out specific protocols affected, e.g., FTP, among others) - port discovery (using a UDP port to discover a service available on a corresponding TCP port, either through broadcast, multicast, or unicast) this is common, and not discussed anywhere see -disc in the IANA ports listing (that suffix has been in use recently, and helps highlight how common the practice is) - service discovery through the DNS (e.g., SRV records) mentioned in 5.2.2, but not here - 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) - 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. - TCP state mechanisms e.g., that might allow a connection that should have been in TIME-WAIT (this is discussed in Sec 5, but not listed as an issue) - address or DNS-name-based signatures as in some X.509 signatures - omits some network issues from the table This is in Sec 11, but missing from the table. See the NAT discussion in draft-ietf-intarea-ipv4-id-update for a related discussion. There appear to be more issues here than just the lack of port numbers. --- ... Issues with IP Address Sharing draft-ietf-intarea-shared-addressing-issues-02 Abstract The completion of IPv4 address allocations from IANA and the RIRs is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These
