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

[Joe Touch <[e-mail]>]

Hi, Mat,

As a followup....

On 2/10/2011 1:26 AM, Matthew Ford wrote:
> 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
>> [e-mail] if you reply to or forward this review.
>>
...
>> Joe
>>
>> --------------------------------------------------------------
>>
>> Transport issues include:
...
>> - 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?

    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;

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

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.

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

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.

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

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)

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

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.
>
> Happy to include some text if you can send it this week.

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