Re: [Int-area] [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address

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

> -----Original Message-----
> From: Matthew Kaufman [mailto:[e-mail]]
> Sent: Monday, August 30, 2010 7:54 PM
> To: Dan Wing
> Cc: 'Joe Touch'; [e-mail]; 'JACQUENET Christian NCPI/NAD/TIP'
> Subject: Re: [Int-area] [BEHAVE] Revealing identity of TCP client
> connection when sharing IPv4 address
> 
> 
>   On 8/30/2010 6:59 PM, Dan Wing wrote:
> >
> > CX-ID is not related to legal inquiries.
> >
> > Rather, CX-ID allows someone running a server to know the same amount
> > of information no matter if the subscriber's ISP operates a NAT
> > (and thus is sharing an IP address with multiple subscribers and
> > sends CX-ID), or if the subscriber's ISP is not operating a NAT (and
> > thus each subscriber gets their own IPv4 address for NNNNN hours,
> > where NNNNN is chosen by the ISP [short values of NNNNN are used by
> > some ISPs rotate IP addresses amongst subscribers to thwart
> subscriber-
> > operated servers]).
> 
> I don't believe it does this. Looking at the IPv4 source address tells
> me a whole lot about the responsible party closest to me. Looking at
> the
> CX-ID tells me... nothing. Unless I have an agreement with the same
> party who is sourcing traffic with that IPv4 address wherein they tell
> me useful things about how they assign CX-IDs.

Yes, I agree an out-of-band agreement such as that might be useful
or might be necessary.

We might also consider some sort of encoding of the CX-ID ("this is
their internal IPv4 address" or "this is the internal VLAN" or
"this is an opaque identifier that is always assigned to this
subscriber").

> And I only care about
> TCP. But for that, we could have a protocol that is more secure *and*
> more reliable *and* doesn't burn up option space... a good starting
> point would be the equivalent of running identd on the NAT box.

Yes, I have considered that as well.  

However, that is a new protocol and adds more latency for that
query; the server would want to wait until the 3-way handshake
completes and then ask the NAT 'who sent that?'  CX-ID is effectively 
as useful as doing that, but CX-ID does not incur the additional
latency.

> Of course all the reasons that identd is pointless apply here as well.

Agreed.

> > My point was that an ISP has no reason, themselves, to operate
> > multiple levels of NAT.  It only costs money.  Tunnels to the 'big
> > NAT' (closest to the Internet) are cheaper and accomplish exactly
> > the same thing, because the peer-to-peer traffic cannot be short-
> > cut between the smaller NATs unless the p2p software is really
> > smart and also able to learn the IP address and port mapping of
> > the intermediate NAT devices.
> And there won't be small ISPs who buy NATed transit from bigger ISPs
> because...?

Those are different administrative domains.  Different companies.
And, yes, they may well start to exist.

As I mentioned, -01 will include text discussing nested NATs and how
they could work with nested CX-IDs.

-d