Subject: Re: [Int-area] TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02

From: Matthew Ford <[email-masked]>
Date: Thu, 10 Feb 2011 10:26:39 +0100

Hi Joe,

Thanks for the detailed review. I've noted inline below where I've tried to address these comments in the latest rev of the draft. There are some questions for clarification below as well.

The revision is here: http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-03

Mat

On 2 Feb 2011, at 02:35, Joe Touch wrote:

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

I've cleaned this up where necessary.

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

Can you clarify what part of section 6 this is referring to?

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

Added a new subsection to §5 Incoming Ports to mention this case. Added to the table.

> 	- service discovery through the DNS (e.g., SRV records)
> 		mentioned in 5.2.2, but not here

I'm not sure I see how this is relevant for inclusion in the table. DNS service discovery is a partial solution to the issue of enabling inbound communications in the presence of address sharing, not an issue caused by address sharing.

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

OK - added to the table, and added some text in a new section on 'Transport Issues'.

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

Added to table and Transport issues section.

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

This isn't necessarily an issue caused by address sharing. It *could* be an issue, if the address sharing mechanism is poorly implemented, but I'm not sure we want to get into all the things that could go wrong in that case.

> 	- address or DNS-name-based signatures
> 		as in some X.509 signatures
> 

I added some text to the Authentication section.

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

The table mentions fragmentation as an issue. I've added some text to highlight that IPID may also be an issue.

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

I added a sentence calling out some of the 'buckets' of issues, but I'm trying to keep the abstract short.

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

I've revised to say IPv6 is the only way to ease pressure without creating the issues identified in the document.

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

No change.

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

I didn't see a lot of subjectivity, but I did a little wordsmithing.

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

Yup.

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

Got it - changed.

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

RFC1340 doesn't speak about dynamic/private ports. I've added a reference to RFC1340 to support definition of Assigned Ports.

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

OK.

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

I've wordsmithed this a little.

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

HTTP is singled out as web servers are especially popular services for end-users to want to run.

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

I've removed the text in parentheses.

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

Some ICMP message types include a fragment of the datagram that triggered the signal to be sent, which is assumed to include port numbers. For some ICMP message types, the Identifier field has to be used as a demuxing token. I've made a number of changes, additions and clarifications to Section 9 to address this better.

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

I've added the point that using IP addresses in this fashion is a heuristic at best and already challenged today by deployed capabilities, e.g. tunnels.

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

As already mentioned, I've cleaned this section up to clarify the situation.

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

I've added this point.

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

Happy to include some text if you can send it this week.

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

I've changed 'exact' to 'in-window' and included a reference to RFC5961. The draft already notes that 'port randomisation is one protection among others against blind attacks.'

> 
> >    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: Joe Touch <[email-masked]>
Date: Tue, 15 Feb 2011 14:00:51 -0800

Hi, Mat,

As a followup....

...
...
> Can you clarify what part of section 6 this is referring to?

    o  Applications that carry address and/or port information in their
       payload - where translation of port and/or address information is
       performed at the IP and transport layers by the address sharing
       solution, an ALG will also be required to ensure application layer
       data is appropriately modified;

> I'm not sure I see how this is relevant for inclusion in the table.
> DNS service discovery is a partial solution to the issue of enabling
> inbound communications in the presence of address sharing, not an issue
> caused by address sharing.

I was referring to the ways in which SRV record use can be interfered
with by address sharing. I.e., this isn't included as a solution issue,
but rather as another area of concern.

> This isn't necessarily an issue caused by address sharing. It
> *could* be an issue, if the address sharing mechanism is poorly
> implemented, but I'm not sure we want to get into all the things that
> could go wrong in that case.

The TCP spec - not implementation - isn't intended to support address 
sharing. An implementation CAN address these issues, but that's no 
different than a similar solution to any other entry in the table, 
AFAICT. The point is that merely sharing the addresses causes problems - 
in this case, inside the TCP stack - that need to be dealt with.

> HTTP is singled out as web servers are especially popular services for end-users to want to run.

It is then worth noting that this mechanism is applicable to few 
currently popular services, e.g., HTTP, SMTP, POP, IMAP, ...

(no need for a long list, but it more clearly states your intent, IMO)

>> ICMP does use port information, notably to demux the the signal to
>> the appropriate transport connection or association. An alternate
>> example might be useful.
>
> Some ICMP message types include a fragment of the datagram that
> triggered the signal to be sent, which is assumed to include port
> numbers. For some ICMP message types, the Identifier field has to be
> used as a demuxing token. I've made a number of changes, additions and
> clarifications to Section 9 to address this better.

FWIW, the point here appears to be:

ICMP does not include its own port number, and messages without a 
payload with its own port number (such as...) may be difficult or 
impossible to map in the presence of address sharing

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

Sorry; this is a bit later than expected. I think you may already have 
addressed this issue in an earlier section, but the point here is as 
follows (in outline form):

- some security IDs are based on IP addresses, which, when shared, may 
compromise the intended protection

- some protocols rely on IP addresses for security associations, which, 
when shared, may compromise the protocols (e.g., not sure what happens 
to IPsec when the SPI database isn't coordinated across machines that 
share an address)

Joe