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

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 17:35:38 -0800

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
[email-masked] 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, [email-masked]) 
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
>    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.

 >  +------------------------------------------------+--------+---------+
 >  |                   Issue                        |   1st  |   3rd   |
 >  |                                                |  party | parties |
 >  +------------------------------------------------+--------+---------+

This table is useful, but the issue descriptions are subjective in some 
cases, where others are objective. All issues should be objectively 
described.

Further, some issues overlap - "Some applications will fail to operate" 
can be related to other issues, e.g., lack of reverse DNS (for apps 
using DNS names for ACLs), lack of ICMP (for apps using transport 
requiring PMTUD, rather than PLPMTUD), etc.

See the primary note above for items missing from this list.

...
>    | Incoming connections to Well-Known Ports will  |    x   |         |
>    | not work                                       |        |         |

This will affect both Well-Known (i.e., user) and System ports. Use the 
term "Assigned Ports" to refer to the sum of both ranges.

> 5.  Port Allocation
...
>    IANA has classified the whole port space into three categories (as
>    defined in http://www.iana.org/assignments/port-numbers):

Cite RFC 1340 here, rather than the web pages; that's where the ranges 
were defined.

It's useful here to define "Assigned" as including both Well-known and 
Registered ranges as well (to refer to it later, e.g., in Sec 6).

...
> 5.2.1.2.  NAT Port Mapping Protocol (NAT-PMP)
>
>    NAT-PMP already has a better semantic here, enabling the NAT to
>    redirect the application to an available port number.

?? This section is brief; it would be useful to explain what is better. 
Is it better because it can use ANY available port number? What defines 
available?

> 5.2.2.  Connection to a Well-Known Port Number
...
>    For example, the use of DNS SRV records [RFC2782] provides a
>    potential solution for subscribers wishing to host services in the
>    presence of a shared-addressing scheme.  SRV records make it possible
>    to specify a port value related to a service, thereby making services
>    accessible on ports other than the Well-Known ports.  It is worth
>    noting that this mechanism is not applicable to HTTP.

It's not clear why HTTP is singled out here. Few of the commonly used 
services rely on SRV records.

> 6.  Impact on Applications
...
>    o  Applications that use fixed ports (e.g., well-known ports) - see
>       Section 5.2.2 for more discussion of this;

Use the term "Assigned" here".

...
>    o  Applications that do not use any port (e.g., ICMP) - where address
>       sharing solutions map subscribers to (private) IP addresses on a
>       one-to-one basis this will not be an issue, otherwise such
>       applications will require special handling - see Section 9 for
>       more discussion of this;

ICMP does use port information, notably to demux the the signal to the 
appropriate transport connection or association. An alternate example 
might be useful.

...
> 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.

...
> 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. When that 
is not available, the demuxing fails. That can impact a number of 
devices, including PMTUD.

> 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.

...
> 13.  Security

This section might also address the impact of sharing on X.509 
authentication, e.g., that signs the name of a host. This can be 
important for some applications.

> 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.

Further, port randomization is just one way to protect a connection 
(another includes timestamp verification, as noted in RFC4953).

 >    A TCP segment is
>    processed only if all previous segments have been received, except
>    for some Reset Segment implementations which immediately process the
>    Reset as long as it is within the Window.

Processing the reset if in-window is valid according to existing 
standards. See Sec 1.1 of
draft-ietf-tcpm-tcpsecure-13; i.e., it is a MAY except where 
specifically warranted.

?? There's also a proposal for an experimental version of TCP-AO that 
supports NAT traversal, FWIW (draft-touch-tcp-ao-nat).

------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Feb 2011 05:03:57 -0300

> too, but has caveats. It should be revised to be more clear about the

+1

> impact of NATs or other sharing techniques.

Agreed. But geo-location is nevertheless widely ued for marketing purposes.

> There are data injection attacks that are possible even without knowing

draft-ietf-tcpm-tcp-security may be of use here.

> (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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Feb 2011 22:10:51 -0800

Joe,

Thanks for your review. A couple of comments inline:

> should, FWIW, be avoided as it is ambiguous (since both User and 
> System ports are registered with IANA).

OK

>         mentioned in 5.2.2, but not here

OK

>         (somewhat related to load balancing in sec 16,   

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?

>         cookie-based systems, such as TCP-CT, TCP with SYN

OK. Interesting.

>         been in TIME-WAIT (this is discussed in Sec 5, but

OK

>         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.

> 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.
>
> ?? The abstract is a bit vague. It would be useful to summarize some 
> of the issues of note.
>
> ...
>> 1.  Introduction
> ...
>>
> ?? In this figure, "x" indicates issues already present with a NAT, 
> and "xx" are for those further issues introduced by pooled sharing.
>
> This table is useful, but the issue descriptions are subjective in 
> some cases, where others are objective. All issues should be 
> objectively described.
>
> Further, some issues overlap - "Some applications will fail to 
> operate" can be related to other issues, e.g., lack of reverse DNS 
> (for apps using DNS names for ACLs), lack of ICMP (for apps using 
> transport requiring PMTUD, rather than PLPMTUD), etc.
>
> This will affect both Well-Known (i.e., user) and System ports. Use 
> the term "Assigned Ports" to refer to the sum of both ranges.
>
>> 5.  Port Allocation
> ...
> ?? This section is brief; it would be useful to explain what is 
> better. Is it better because it can use ANY available port number? 
> What defines available?
>

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.

> transport header to enable port demuxing at the end receiver. When 
> that is not available, the demuxing fails. That can impact a number of 

Right.

> 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?)

> There are data injection attacks that are possible even without 
> knowing the exact SN.
>

Jari

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 09:38:54 -0800

Hi, Fernando,

...
> 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.

> 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.

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 03 Feb 2011 06:55:21 +0900

Joe Touch wrote:

> 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".

> when viewed from the outside.

Port based redirection MUST be done after fragmentation reassembly.

That's all and is no special.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 14:04:21 -0800

Hi, Jari,

Notes below...

Joe

On 2/1/2011 10:10 PM, Jari Arkko wrote:
...
>> (somewhat related to load balancing in sec 16, but not necessarily)
>

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,

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.

...
> 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).

...
> 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.

...
> the existing BEHAVE RFCs say something about IPID allocation/change by

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

---

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 14:14:54 -0800

> 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).

> used (overridden) as source and destination port numbers,

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.

> 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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Feb 2011 22:04:51 -0300

> 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.

> 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).

> 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,

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 17:08:39 -0800

On 2/2/2011 5:04 PM, Fernando Gont wrote:
...
> 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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Feb 2011 22:24:30 -0300

> When I tunnel using an ISI address, whomever sees my address thinks I'm
[..]

Ok.. I see. I was thinking about tunnels in the infrastructure. -- those
are transparent in this respect.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Feb 2011 22:30:04 -0300

>> When I tunnel using an ISI address, whomever sees my address thinks I'm

And one might argue that, in this type of scenario, this "breakeage" of
geo-location might, in some cases, be desirable.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 17:49:25 -0800

> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 17:49:58 -0800

> are transparent in this respect.

Yes. It's tunnels at the endpoints I'm using as an example here.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Feb 2011 23:44:28 -0300

Joe,

> 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,

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 03 Feb 2011 18:48:29 +0900

> 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.

> to *carry* port numbers of the messages that caused their generation (if 

FYI, traceroute both with UDP or ICMP ECHO is working to/from
/between private network behind end to end gateway is working.

> is reassembled at the NAT itself.

IC. We can rely on random id and transport checksum, then.

> 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

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Feb 2011 10:11:18 -0800

...
> /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.

> 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).

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Feb 2011 06:39:27 +0900

> of the packet that causes the ICMP.

Yes, ICMP time exceeded including UDP can be routed and is actually
working.

> 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).

> 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.

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Feb 2011 06:55:37 +0900

> 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