Re: [Int-area] Revving draft-intarea-shared-addressing-issues

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Matthew Ford [mailto:[e-mail]] 
> Sent: Thursday, June 10, 2010 6:00 AM
> To: [e-mail]
> Cc: [e-mail]; Brian 
> E Carpenter; Lorenzo Colitti; Dan Wing
> Subject: Revving draft-intarea-shared-addressing-issues
> 
> Hi,
> 
> I'd like to revise draft-intarea-shared-addressing-issues in 
> time for IETF78. I've listed the comments I've received since 
> the previous version was submitted and presented in Anaheim 
> below. Before I put keyboard to xml, are there any further 
> comments on the current document?
> 
>  o Augment the table in §3 to include a column identifying 
> whether the issues apply to NAT44.
> 
>  o Add a section taking a content provider as an example of a 
> 3rd party, and detail the issues that apply specifically.
> 
>  o Add some text to clarify that whether we're talking about 
> DS-LITE, NAT64 or NAT444 isn't especially important - it's 
> the view from the outside that matters, and given that, most 
> of the issues apply regardless of the specific address 
> sharing scenario in question.

That would be good.  Should be NAT44 (not "444"), though.  The
problem of IP address sharing is orthogonal to the subscriber
operating their own NAT in their house (which is one of the
4's of NAT444).


As another addition, do you perhaps want to point out that
all IP address sharing mechanisms (proposed to date) are
limited to TCP, UDP, and ICMP, thereby preventing end users 
from fully utilizing "The Internet" (e.g., SCTP, DCCP, 
RSVP, protocol 41 (IPv6-over-IPv4), protocol 50 (IPsec ESP)).

-d


>  o Revise the first portion of §10 as follows:
> 
> "In many jurisdictions, service providers are legally obliged 
> to provide the identity of a subscriber upon request to the 
> appropriate authorities.  Where one public IPv4 address is 
> shared between several subscribers, the knowledge of the IP 
> address alone is not enough to identify the appropriate 
> subscriber.  The legal request should include the 
> information: [IP address - Port - Protocol- Begin_Timestamp - 
> End_Timestamp]. Accurate time-keeping (e.g. use of NTP or 
> SNTP) is vital because port assignments are dynamic.  A 
> densely populated CGN could mean even very small amounts of 
> clock skew between a content provider and the CGN operator 
> will result in ambiguity about which customer was using a 
> specific port at a given time.
> 
> Considering that it is unrealistic to expect all servers to 
> start logging port information of connection attempts, 
> address sharing service providers may need to start logging 
> IP destination addresses as well, giving rise to privacy concerns.
> 
> If multiple subscribers are accessing the same (popular) 
> server at nearly the same time, it can be impossible to 
> disambiguate which subscriber accessed the server, especially 
> with protocols that involve several connections (e.g. HTTP).  
> Thus, logging the destination address on the NAT is inferior 
> to logging the source port at the server.
> 
> If the server is not logging source port numbers and the NAT 
> is not logging destination IP addresses, the service provider 
>  cannot trace the offending activity to a specific 
> subscriber. In this circumstance, the service provider would 
> need to disclose the identity of all subscribers who had 
> active sessions on the NAT during the time period in 
> question. This may be a large number of subscribers."
> 
>   - Mat
> 
>