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

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 Aug 2010 15:10:29 -0700

Please send replies to [email-masked]

Hi.  

Andrew and I have written two I-D's describing two approaches to solve a
problem that occurs when sharing an IPv4 address (NAPT44, NAPT64, HTTP
proxy, A+P, dual-IVI, etc.).  The abstract is common between the two
approaches and summarizes the problem:

   When an IP address is shared among several subscribers, it is
   impossible to  determine which subscriber has initiated that TCP
   connection.  This memo describes a technique to share the identity of
   a subscriber that initiated a TCP connection with the TCP server.
   The proposed method avoids altering the application-level payload
   and works well with SSL-protected connections.

approach 1, new TCP option:
  http://tools.ietf.org/html/draft-wing-nat-reveal-option

approach 2, overload existing TIMESTAMP TSVal option and IP ID:
  http://tools.ietf.org/html/draft-yourtchenko-nat-reveal-hash

We are leaning towards the new TCP option (approach 1).

The idea crosses BEHAVE (NAT), INTAREA (address sharing), and TCPM (TCP
option).  However, to reduce cross-posting and because INTAREA already has a
working group document related to address sharing, I propose we discuss the
document on the [email-masked] mailing list.

Comments and feedback welcome.
-d

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 Aug 2010 08:48:15 +0300

Hi,

>  http://tools.ietf.org/html/draft-yourtchenko-nat-reveal-hash

why is this a problem that needs to be solved, why at the transport layer and why is a solution that only works for TCP useful?

I mean, what you're really doing is introducing an identity layer, and we have e.g. HIP for that already, which is doing this in a clean way with identities that are actually cryptographically useful. I feel like I'm missing something.

> We are leaning towards the new TCP option (approach 1).

We're severely restricted with TCP option space, esp. on SYN packets. Burning up to 10 option bytes for an ID option will simply not fly.

Lars

---

From: <[email-masked]>
Date: Thu, 26 Aug 2010 08:05:31 +0200

Dear Dan, all,

The problem space of these two drafts is a valid problem. In our case (DS-Lite CGN), we have investigated the header injection approach (especially adding an XFF) to convey the IPv6 of the client. The identifier which will be conveyed in an XFF may be any identifier that unambiguously identifies the customer. We have identified two options where to enforce the header injection:

(1) CP router: it is aware of the IPv6 prefix allocated to the customer.
(2) or in CGN: will insert the source IPv6 address or the first x bits of the tunnel ID. 

This approach has known security issues but mitigates the issue we have: i.e., be able to do implicit authentication based on the source IP address (some services uses the source IP address for authenticating the users.

As far as our internal services are concerned, our recommended solution is to be IPv6-enabled.

I personally like the idea of defining a new TCP option, but this approach suffers from the same security issues as for XFF. Furthermore, if the option carries a private IPv4 address or a local identifier, the examples listed in the draft are not valid: blacklist a user, geo-localisation, etc. you can not do geo-localisation with a private IPv4 address used by hosts behind an AFTR for instance. This means that the option can not achieve the goal for which it has been defined. 

That's said, in addition to the semantic, the draft needs to elaborate the information to be carried in that option to achieve the goal it has been designed for. Additionally, end hosts may not be the appropriate place to add that option, the CP router (not necessarily the NAT device) may be a candidate place as for the XFF case I mentioned above.

I personally suggest that we focus first to identify the requirements to be met by any solution claiming the solve the problem and then analyse the solutions we have on the table.

Note that a candidate solution is to say: Don't define any new IPv4 solution for this problem because this would (hopefully) encourage porting these services to IPv6. CGN should stay evil boxes.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : jeudi 26 août 2010 00:10
À : [email-masked]; [email-masked]; [email-masked]
Objet : [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address

Hi.  

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 26 Aug 2010 10:09:15 -0700

[Re-sending as I wasn't an int-area list member at the time this was sent]

> Please send replies to [email-masked]
Done.
> Comments and feedback welcome.

I don't see consideration given to:

1) The ramifications of overwriting the existing CX-ID option in the 
double (triple, etc.) NA(P)T scenario. We know that this will continue 
to increase in prevalence, at least for the IPv4 Internet and it. It is 
not at all clear to me that the goals ("geolocation, DoS blocking, and 
spam blacklists") will be met by this proposal as additional layers of 
NAT become commonplace. It seems that a solution which preserves all 
identifiers, or possibly even *just the first* identifier added 
(assuming the identifier space is sufficiently unique and not, say, 
RFC1918 IPv4 addresses), would be superior for meeting the stated goals.

2) Whether or not existing NA(P)T devices will in fact operate properly 
if the "client" side connections have a CX-ID option present. (This is 
arguably their problem, but if there is a large deployed base of such 
devices then double-NAT with such broken devices on the outside and new 
devices implementing this option will fail in confusing-to-the-user ways).

Also, both these issues are arguably more in the domain of BEHAVE, but 
I've removed that from the CC list as requested.

Matthew Kaufman

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 Aug 2010 13:16:15 -0700

It seems like the source prefix is usable at the IP layer. As noted, the global address of the NAT becomes a proxy for the set of systems behind it; the IPv6 source prefix being a similar proxy is no worse. 

I'd also note that for those systems that use the MAC Address in the EID, one can in fact use the /128, or the lower 64. That concern was, after all, the drive behind privacy addressing.

Frankly, I have some concern with using something embedded in the message. It seems likely that if something is created or selected as a primary vehicle for the purpose that the bad guys can generate, the bad guys are smart enough to game that system - not include it, include it but randomize it, etc. If you decide you want the first hop MTA to put it in, there comes a question why you don't suggest DKIM, as that is precisely its intention - the domain vouches for the email coming from it.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Aug 2010 21:49:26 -0700

> -----Original Message-----
> From: Matthew Kaufman [mailto:[email-masked]]
> Sent: Wednesday, August 25, 2010 4:23 PM
> To: [email-masked]
> Cc: Dan Wing
> Subject: Re: [BEHAVE] Revealing identity of TCP client connection when
> sharing IPv4 address
> 
> 
> to increase in prevalence, at least for the IPv4 Internet and it. 

We added text to -01 (which isn't yet published) to discuss the
case where CX-ID is added by different levels of address sharing
devices.

However, I do not forsee an ISP installing multiple levels of 
address sharing devices; the one closest to the Internet would 
maintain state of all of the devices behind it, and there isn't
a way to short-circuit traffic between the interior address sharing
devices unless there is very smart peer-to-peer software which is
provided a way to learn the short-circuit addresses (e.g., a STUN
server between each address-sharing device and a way for the p2p
software to learn of those STUN servers).

> It is

We're still tweaking our text in -01, but I expect the text will
clarify that.  

> devices implementing this option will fail in confusing-to-the-user

This will also be discussed more fully in -01.

> I've removed that from the CC list as requested.

Any sort of address sharing would benefit from a technique to identify
which subscriber generated the packet.  NAT also comes to my mind
immediately, but so does A+P (which doesn't NAT), and HTTP proxies
do the same sort of address sharing (but can insert X-Forwarded-For,
until HTTPS ("CONNECT") happens).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Aug 2010 22:00:37 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, August 25, 2010 11:06 PM
> To: Dan Wing; [email-masked]
> Cc: JACQUENET Christian NCPI/NAD/TIP
> Subject: RE: [BEHAVE] Revealing identity of TCP client connection when
> sharing IPv4 address
> 
> Dear Dan, all,
> 
> The problem space of these two drafts is a valid problem. In our case
> (DS-Lite CGN), we have investigated the header injection approach
> (especially adding an XFF) to convey the IPv6 of the client. The
> identifier which will be conveyed in an XFF may be any identifier that
> unambiguously identifies the customer. We have identified two options
> where to enforce the header injection:
> 
> This approach has known security issues

Today, without an ISP-operated NAT, a subscriber exposes their 
IPv4 address to a server when the subscriber sends a packet to the
server.

How do those security issues differ from today?  

> but mitigates the issue we
> have: i.e., be able to do implicit authentication based on the source
> IP address (some services uses the source IP address for authenticating
> the users.
> 

Makes sense.

> I personally like the idea of defining a new TCP option, but this
> approach suffers from the same security issues as for XFF. Furthermore,
> if the option carries a private IPv4 address or a local identifier, the
> examples listed in the draft are not valid: blacklist a user, geo-
> localisation, etc. you can not do geo-localisation with a private IPv4
> address used by hosts behind an AFTR for instance. This means that the
> option can not achieve the goal for which it has been defined.

The user is not identified solely by the CX-ID; the user is identified
by the CX-ID and the public IPv4 address of the NAT (address sharing
device).  

So, let's say that an ISP is operating a NAT with public IP address
192.0.2.1, and a subscriber has IP address 192.168.1.1.  The subscriber
sends a TCP SYN to a server at 1.1.1.1.  The ISP's NAT inserts a 
CX-ID that might contain 24 bits (168.1.1), or a VLAN-ID and 32 bits,
or whatever the ISP's NAT was programmed to insert as the CX-ID.  The
server will receive the TCP SYN from 192.0.2.1 and see there is also
a CX-ID.  The server can -- if it wishes -- combine 192.0.2.1 with
the CX-ID to look up information in its own database of locations,
good users / bad users, or whatever.

How the server populates its database of locations, its database
of good users, or its database of bad users, is entirely up to that
server.  It is outside the scope of this draft. 

Today, there is no IETF document or specification that explains
how ISPs know where in the world a certain IP address is located.
However, there are services that provide that information.  We can
reasonably expect such services to deal with additional 
information in CX-ID.

> That's said, in addition to the semantic, the draft needs to elaborate
> the information to be carried in that option to achieve the goal it has
> been designed for. Additionally, end hosts may not be the appropriate
> place to add that option, the CP router (not necessarily the NAT
> device) may be a candidate place as for the XFF case I mentioned above.

I don't see value in distinguishing individual hosts behind a customer
premise router.  Afterall, that isn't done today.  But today it is
possible to distinguish between subscribers, by using the IPv4 address
as the distinguisher (identifier).

> I personally suggest that we focus first to identify the requirements
> to be met by any solution claiming the solve the problem and then
> analyse the solutions we have on the table.

My primary requirement is that we maintain the ability for servers
to distinguish amongst subscribers sharing an IPv4 address.

> Note that a candidate solution is to say: Don't define any new IPv4
> solution for this problem because this would (hopefully) encourage
> porting these services to IPv6. CGN should stay evil boxes.

As discussed in the I-D, the only way to reach that goal is for a 
server to not listen on IPv4.  

Please email me when your mail server or commercial website is no 
longer listening on IPv4.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Aug 2010 22:09:04 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lars Eggert
> Sent: Wednesday, August 25, 2010 10:48 PM
> To: [email-masked]
> Subject: Re: [Int-area] [BEHAVE] Revealing identity of TCP client
> connection when sharing IPv4 address
> 
> Hi,
> 
> why is this a problem that needs to be solved,

There are criminals on the Internet who launch attacks, and those
criminals will continue to operate after the installation of NAT44
and NAT64 devices, and will be able to hide their activities more
successfully.  

> why at the transport layer 

Most interesting applications operate over TCP.

> and why is a solution that only works for TCP useful?

We could define a new IP option.  Would that be more appealing?

> I mean, what you're really doing is introducing an identity layer, and
> we have e.g. HIP for that already, which is doing this in a clean way
> with identities that are actually cryptographically useful. I feel like
> I'm missing something.

We need something incrementally deployable by ISPs deploying NAT44,
NAT64, and A+P.

I admit that I don't know HIP well enough to know if an ISP could 
inject HIP into a user's connection initiation to cause the user
to be identified.  But I don't think it can.

> We're severely restricted with TCP option space, esp. on SYN packets.
> Burning up to 10 option bytes for an ID option will simply not fly.

This problem is assuaged by the technique described in
http://tools.ietf.org/html/draft-wing-nat-reveal-option-00#section-5
which proposes sending one option in the SYN without any data 
(consuming two bytes of option space) and sending the actual 
informational element in the first ACK (up to 8+2=10 bytes); that 
first ACK is usually devoid of options payloads so should have
space for the 8 byte option payload.

-d

---

From: Lars Eggert <[email-masked]>
Date: Mon, 30 Aug 2010 09:42:48 +0300

Hi,

> and NAT64 devices, and will be able to hide their activities more

but all this option would do is take us back to where we are today (while adding significant amounts of complexity). It doesn't actually solve anything.

> We could define a new IP option.  Would that be more appealing?

Yes, because if I understand your mechanism correctly, you're transmitting data about a subscriber and his IP address and not something about a particular TCP connection.

> We need something incrementally deployable by ISPs deploying NAT44,

Who is supposed to look at the contents of this option at the other end? The server? Or will the ISP at the other side strip the option?

> space for the 8 byte option payload.

TCP options are not reliably transmitted. In other words, if that first segment is lost and the payload bytes it contained are retransmitted, the retransmitted segment is not required to contain the same options as the lost segment. (Introducing this requirement would update RFC793.) You'd need to cook your own reliability scheme with an "I got your option" ACK option, but this is ugly as hell.

Please find a solution that doesn't modify TCP.

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Aug 2010 10:26:03 -0700

> by the CX-ID and the public IPv4 address of the NAT (address sharing

Strictly, the user is identified behind the NAT as:

	src IP
	dst IP
	src port
	dst port

A NAT typically scrambles src IP and src port.

CX-ID corrects for the src IP - when used in conjunction with the 
received IP address, as you note.

However, you're still missing info on the src port. You can claim that 
CX-ID corrects for IP address, but without the src port similarly 
protected, you don't have a "user" identity.

Further, this works only one level; it means that you see one level back 
into NATs leading to your net. It won't then resolve multiple layers of 
NATs, e.g.:
	
	user1 ---+
                  NAT1---+
	user2 ---+      |
	                NAT2----->
	user3 ----------+

Users 1 and 2 will look like they come from the same CX-ID, but they're 
different users (differentiated by source port). That's why the CX-ID 
coming after the second NAT needs to retain port info too.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2010 10:55:04 -0700

> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, August 30, 2010 10:26 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 'JACQUENET
> Christian NCPI/NAD/TIP'

Er, I'm missing something.

Let's look at things without NAT for a second.  An ISP gives a 
subscriber an IPv4 address, usually via DHCP or PPPoE.  This is given 
to a single computer at the subscriber's home.  That subscriber is 
identified by that IPv4 address (to the entire Internet) and 
their home's physical address (known only to their ISP).

Sometime soon thereafter, the subscriber installs a NAT, possibly 
because they want WiFi, they have more than one computer that needs 
to access the Internet, or whatever.  That NAT now obtains the IP
address from the ISP (still using DHCP or PPPoE).  There are multiple
hosts behind that NAT.  But those hosts appear to the Internet 
and to the ISP as the same subscriber -- the same home with the 
same physical address.

Are you wanting that home NAT to distinguish between connections
made by the different hosts behind the NAT?  If so, I don't
see how source port identifies the different hosts.

I do not have any reason for that level of identification.

If the problem is my use of the term "user" (appears twice in the
document), I can certainly correct that in -01 by using subscriber
(appears 5 times in the document).

> coming after the second NAT needs to retain port info too.

Text will be added to -01 which explains how multiple levels of 
CX-ID-supporting NAPT devices can function together.  However, I do
not envision any ISP deploying multiple levels of NAPT, because
doing so adds to their costs with no associated operational savings.

-d

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Aug 2010 11:03:09 -0700

Hi, Dan,

> see how source port identifies the different hosts.

You're assuming you know who deploys NATs.

Yes, as far as the ISP is concerned, this is one "user" on their 
network. But it isn't one "user" viewed more than one step away.

I.e., it won't work for transit ISPs at all. It works only for stub 
ISPs, and only to the extent that it maps to one IP address.

(that said, I agree with Lars that there are many reasons not to do 
this, and not to do this within a TCP option regardless; at best, this 
is an IP option issue)

Finally, for the same reason that NATs intentionally merge things onto 
one IP address, I expect they - or someone else - will deploy devices 
that intentionally merge CX-IDs for the same reason.

...
> (appears 5 times in the document).

I'm not sure if subscriber is right either. You really want "IP address 
as assigned"; that's more than just a subscriber (host subscriber? 
subscriber host?)

> doing so adds to their costs with no associated operational savings.

Just because we're not seeing the immediate benefits, doesn't mean it 
won't be used that way. ;-) The question is whether - even if something 
unrealistic or unintentional occurs - does the result still make sense?

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2010 11:07:48 -0700

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Sunday, August 29, 2010 11:43 PM
> To: Dan Wing
> Cc: [email-masked]
> but all this option would do is take us back to where we are today
> (while adding significant amounts of complexity).

Yes, agreed.

> It doesn't actually solve anything.

I agree it does not block criminal activity.

I disagree it solves nothing, though.

> Yes, because if I understand your mechanism correctly, you're
> transmitting data about a subscriber and his IP address and not
> something about a particular TCP connection.

Ok, I'll see what I could cook up around an IP option.

> Who is supposed to look at the contents of this option at the other
> end? The server? Or will the ISP at the other side strip the option?

The TCP server.

> TCP options are not reliably transmitted. In other words, if that first
> segment is lost and the payload bytes it contained are retransmitted,
> the retransmitted segment is not required to contain the same options
> as the lost segment. (Introducing this requirement would update
> RFC793.) You'd need to cook your own reliability scheme with an "I got
> your option" ACK option, but this is ugly as hell.
> 

Yes, I will investigate doing this at the IP layer.

I realize nobody wants this problem solved at their favorite layer.

Yet, the problem needs to be solved until we have *turned off* IPv4
servers.

-d

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Aug 2010 11:18:13 -0700

On 8/30/2010 11:07 AM, Dan Wing wrote:
...
> Yet, the problem needs to be solved until we have *turned off* IPv4

s/servers/NATs/

:-)

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2010 11:19:41 -0700

> Sent: Monday, August 30, 2010 11:03 AM
> To: Dan Wing

No.  

Rather, I don't care if a subscriber installs a NAT.  I can't
reliably detect if they have or have not installed a NAT today,
and this TCP option (or an IP option) doesn't help with that,
either.

Rather, this option is intended to be used by a service provider
that is sharing an IP address amongst several subscribers.

> network. But it isn't one "user" viewed more than one step away.

Same is true with today's in-home NATs, though.  But I do not 
really care to distinguish the various hosts operated behind that
in-home NAT.

> ISPs, and only to the extent that it maps to one IP address.

I am not aware of a transit ISP that NATs traffic coming from
an access ISP.  They probably exist (everything exists), but 
they are not typical.

> that intentionally merge CX-IDs for the same reason.

Sure.  Or they might also deploy address sharing without support for 
CX-ID, which is effectively the same when viewed from the Internet.

-d

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 30 Aug 2010 13:51:04 -0700

> case where CX-ID is added by different levels of address sharing
I'll look when it comes out.
> address sharing devices; ...
Totally disagree. This proposal only makes sense if the far end can do 
something with the identity.

There are only two things you can do. 1) Log it for forensic analysis 
later, and 2) Base access control, geographic limitations or decisions, 
or other real-time behavior on the identifier.

In case 1, you can already just log the address and port and go subpoena 
the ISP with the NAT to get the records. Logging one more thing simply 
moves a small part of the indexing problem from them to you.

In case 2, a single identifier is nearly useless. Consider the following 
situation:

I run an intranet server. It has external access via HTTPS, but I also 
want to filter so you can't even connect unless you're one of my 
employees. Today, my employee has an ISP assigned address of 1.2.3.4. 
(And the ISP got that from *their* upstream, as they're small and don't 
have any PI space) So I put that in the allow list. (Never mind that 
this isn't very secure, but lets pretend for now that it is.)

Tomorrow, my employee's ISP runs out of IPv4 addresses, so they start 
using CGN and put everyone behind it. My employee is now at 1.2.3.1 but 
so is everyone else at that ISP. They helpfully identify him using a 
CX-ID of 4.5.6.7.

I put "allow CX-ID 4.5.6.7" in my ACL (instead of "allow IP 1.2.3.4").

The next day, my employee's ISP changes upstream providers. Their new 
upstream is also out of IPv4 addresses and since they can't give my 
employees ISP a real IPv4 PA address, they give them a CGN-provided 
address of 10.7.8.9 for *their* CGN's outside address.

But now the new upstream ISP's NAT *overwrites* the CX-ID of 4.5.6.7 
placed there by the employee's ISP and replaces it with 9.9.9.1 or 
something. Totally breaks my ACL. (Never mind, again, that it was never 
secure in the first place).

If addresses ever do run out, there will be multiple levels of address 
sharing. There already are in big enterprises... the conference rooms 
have wireless access points that NAT to the inside net at the remote 
office. The inside net at the remote office is NATed to the single 
address routed over the VPN from the head office. Etc. Every time you 
overwrite the ID, you destroy some useful information that the far end 
could have used... if, indeed the far end can trust any of this 
information at all. If it can't, then this proposal *also* has no reason 
to exist.

> until HTTPS ("CONNECT") happens).
Yes. A technique which *securely* identifies the subscriber who 
generated the packet, in a way which isn't lost as it travels through 
multiple levels of address translation and in a way which isn't so 
trivial to forge as to be useless as "a technique to identify which 
subscriber generated the packet" would be a good thing to have in order 
to continue making decisions based on subscriber identity which will be 
lost as CGN becomes more prevalent. Neither of these proposals solves 
that problem.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 30 Aug 2010 14:03:06 -0700

> that is sharing an IP address amongst several subscribers.
Why does the service provider need to send this information onward to 
anyone? They need to log the translations they've done in order to 
respond to legal inquiries about what subscriber was using what public 
address. That's just as easy as logging the CX-IDs one has assigned for 
the same translations.

And since the service provider can't *securely* pass this information 
onward (in either of these proposals), there's nothing to be gained by 
looking at it over at the far end.

> an access ISP.  They probably exist (everything exists), but
They are not typical *now*. This proposal intends to address a future in 
which ISPs put their customers behind NAT much more often than they do 
now. Some of those customers will undoubtedly be entities which are, or 
act as, ISPs themselves. (Even a coffee shop with a DSL line becomes one 
the moment they fire up free WiFi for the patrons)

Matthew Kaufman

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2010 18:51:59 -0700

> Sent: Monday, August 30, 2010 1:51 PM
> To: Dan Wing
> Cc: [email-masked]

In the first place, though, when the employee's ISP changes upstream
providers, the ACL breaks -- irrespective of any NAT by the ISP.

> information at all. If it can't, then this proposal *also* has no
> reason to exist.
> 
> >

I'm only trying to build something that works as well as today's
IPv4 address to 'identify' a subscriber.  

I certainly agree that IPv4 addresses are poor identifiers.  I mean,
that was pretty well proven when everyone quit using R* services
in the 1990s.

Yet, it is helpful to distinguish between subscribers that are sharing
an IP address.  One of the subscribers might be trying to submit 1,000
votes to an online poll, while the other 5,000 subscribers are behaving
like sane users (and voting into the online poll only once).  

For email, one subscriber might have a virus and is posting tens of
thousands of messages to webservers or via SMTP.  Yet there are thousands
of other subscribers also using that IP address, behaving normally.

I am trying to improve the situation for those good users who are 
sharing an IP address with a bad user.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2010 18:59:56 -0700

> Sent: Monday, August 30, 2010 2:03 PM
> To: Dan Wing
> Cc: 'Joe Touch'; [email-masked]; 'JACQUENET Christian NCPI/NAD/TIP'
> address.

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

> That's just as easy as logging the CX-IDs one has assigned for
> the same translations.
> 

I agree CX-ID isn't secure.  It isn't intended to be secure.  It is
intended to be as secure as the source IPv4 address in the TCP SYN --
which is in the clear and can be spoofed.  Completion of the 3-way
handshake proves return routability, but does not make it terribly
secure.

> the moment they fire up free WiFi for the patrons)

A coffeeshop operating a NAT, which is connected to an ISP 
operating a NAT, is in the same situation as a home operating
a NAT connected to an ISP operating a NAT.

Those coffee shops, today, acquire a poor reputation if one of their
customers starts spamming websites, doing too many searches on any
of the major search engines, or any other variety of things.  

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.

-d

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 30 Aug 2010 19:53:35 -0700

> some ISPs rotate IP addresses amongst subscribers to thwart subscriber-
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. 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.

Of course all the reasons that identd is pointless apply here as well.
> the intermediate NAT devices.
And there won't be small ISPs who buy NATed transit from bigger ISPs 
because...?

Matthew Kaufman

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2010 20:56:41 -0700

> Sent: Monday, August 30, 2010 7:54 PM
> To: Dan Wing
> 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

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.

> And there won't be small ISPs who buy NATed transit from bigger ISPs

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Aug 2010 11:33:19 -0700

A paper was published in 2004 which analyzed the success of new IP options
and new TCP options,

  "Measuring Interactions Between Transport Protocols and Middleboxes"
  Alberto Medina, Mark Allman, Sally Floyd
  http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf

In Section 4.3, it showed a new IP Option resulted in a 70% connection
failure, whereas
Section 4.4 shows a new TCP option resulted in only a 0.2% connection
failure.  I do 
not expect things have improved on the Internet for IP options, and my
testing with 
nmap to the top 500 websites also has very high failure when sending an TCP
SYN
with an IP option.

Using an IP Option on today's Internet seems unworkable, unless we do
something
creative like sending two packets (one with the IP option, one without) and
react accordingly.  This will probably break UDP-based application protocols

that don't expect packets to arrive twice, and of course doubles traffic for
TCP until the address sharing device learns if the server supports or
rejects
IP options - which is more state to maintain.

Are there other ideas for how to successfully introduce a new IP option to 
the IPv4 Internet?

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Aug 2010 12:47:33 -0700

Hi, Dan,

On 8/31/2010 11:33 AM, Dan Wing wrote:
> In Section 4.3, it showed a new IP Option resulted in a 70%
> connection failure, whereas Section 4.4 shows a new TCP option
> resulted in only a 0.2% connection failure. I do not expect things
> have improved on the Internet for IP options, and my testing with
> nmap to the top 500 websites also has very high failure when sending
> an TCP SYN with an IP option.
>
> something creative like sending two packets (one with the IP option,
> one without) and react accordingly. This will probably break
> UDP-based application protocols that don't expect packets to arrive
> twice,

Only ones that are already broken. UDP runs over IP, and IP does not 
guarantee that packets are not replicated. Protocols that care about 
loss, ordering, or duplication need to check that at the application 
layer or use something like TCP instead.

 > and of course doubles traffic for TCP until the address
> sharing device learns if the server supports or rejects IP options -
> which is more state to maintain.
>
> Are there other ideas for how to successfully introduce a new IP
> option to the IPv4 Internet?

Most have moved the option into a shim layer, i.e., changing from loose 
source route into IP-in-IP encapsulation. For what you want to do, 
IP-in-IP seems like it does the right thing - only the outermost IP 
would be NAT'd - but it would make some other parts of the protocol more 
complex.

JOe

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 31 Aug 2010 13:15:24 -0700

>> Of course all the reasons that identd is pointless apply here as well.
As long as we agree on this, I think we're all set.
> they could work with nested CX-IDs.
Look forward to seeing it.

Matthew Kaufman