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

Jari Arkko <> Wed, 02 February 2011 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B23D3A6CF9; Wed, 2 Feb 2011 06:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.497
X-Spam-Status: No, score=-99.497 tagged_above=-999 required=5 tests=[AWL=-2.967, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, GB_SUMOF=5, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DT+mRmFYumzG; Wed, 2 Feb 2011 06:31:32 -0800 (PST)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id DAF693A6C68; Wed, 2 Feb 2011 06:31:31 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A09E2CC2D; Wed, 2 Feb 2011 16:34:51 +0200 (EET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZSfEHNK2r2Cr; Wed, 2 Feb 2011 16:34:49 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id C37922CC3C; Wed, 2 Feb 2011 16:34:48 +0200 (EET)
Message-ID: <>
Date: Tue, 01 Feb 2011 22:10:51 -0800
From: Jari Arkko <>
User-Agent: Thunderbird (X11/20101027)
MIME-Version: 1.0
To: TSV Dir <>
Subject: Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>,, IETF discussion list <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Feb 2011 14:31:34 -0000


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


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

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)


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

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.

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

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 

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