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