Subject: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT

From: <[email-masked]>
Date: Tue, 15 Mar 2011 14:49:06 +0100

Dear authors,

As you know, several issues are encountered when CGNs are used (see http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for more details).

In order to mitigate some of the issues listed in the above I-D, the CGN may inject an information which will be used by remote servers to disambiguate users. FWIW, http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01 analyzes a set of candidates solutions and identifies some limitations.

IMHO, it is valuable to add a requirement in the I-D among these lines.

Cheers,
Med

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Mar 2011 10:27:41 -0400

On 2011-03-15 09:49, [email-masked] wrote:
> As you know, several issues are encountered when CGNs are used (see
> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for
> more details).
>  
> In order to mitigate some of the issues listed in the above I-D, the CGN
> may inject an information which will be used by remote servers to
> disambiguate users. FWIW,
> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01 analyzes
> a set of candidates solutions and identifies some limitations.
>  

I'll definitely need WG feedback on this.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 08:23:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, March 15, 2011 6:49 AM
> To: [email-masked]
> Cc: 'behave' <([email-masked])>
> Subject: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT
> 
> Dear authors,
> 
> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-
> 05 for more details).
> 
> In order to mitigate some of the issues listed in the above I-D, the
> CGN may inject an information which will be used by remote servers to
> disambiguate users. FWIW, http://tools.ietf.org/html/draft-boucadair-
> intarea-nat-reveal-analysis-01 analyzes a set of candidates solutions
> and identifies some limitations.
> 

I agree it would be valuable.

How about in CGN Requirements "bis", though?  I would hate to delay
publication of the CGN Requirements draft while we're working through
which mechanism to standardize.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 11:46:00 -0400

I believe we need much more discussion on this requirement before it makes
to the I-D. There are security issues, subscriber privacy issues,
performance issues, amongst others. Not to mention that there are some 6
different techniques.

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 16:54:44 +0100

Hi Reinaldo,

Yes, this needs discussion. 

As for the privacy, I don't see an issue there since the exposed information is the same as the source IP address (when there is no NAT). 

Cheers,
Med

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 12:11:45 -0400

On 3/15/11 8:54 AM, "[email-masked]"
<[email-masked]> wrote:

> As for the privacy, I don't see an issue there since the exposed information
> is the same as the source IP address (when there is no NAT).

If you take NAT as the new baseline, then there is a change in relation to
that. Look at this another way. Will this requirement apply to CPEs as well
so third parties can differentiate between several users at the home? Why
not?

BTW, Can you explain who this requirement will benefit?

> Cc : 'behave' <([email-masked])>;
> [email-masked]

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 17:47:29 +0100

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 17:12
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault
Cc : 'behave' <([email-masked])>; [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT

Med: I see your point and it is a valid question. The requirement is about the CGN and not the NAT in the CPE. Some of the solutions are already deployed (e.g., use of XFF by load-balancers). BTW, there are already reported issues with current practices: see for instance the S. Bellovin's study about counting NATed hosts.

Med: It benefits to the users, service providers and content providers: 
* a user won't be impacted by a misbehaving action of another user sharing the same IP address. See http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01#section-1 for more details.
* a service provider won't receive calls to hot-lines (OPEX reduction)
* content providers: service experience.

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 17:53:26 +0100

Hi Dan,

If there is a risk to delay the publication of the document, an option would be to have a non-normative section to record the issue and to discuss it without providing an explicit requirement. This works for me.

BTW, does the work documented in nat-reveal-analysis I-D within the charter of BEHAVE or not?

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 16:24
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 10:19:18 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 9:53 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT
> 
> Hi Dan,
> 
> If there is a risk to delay the publication of the document, an option
> would be to have a non-normative section to record the issue and to
> discuss it without providing an explicit requirement. This works for
> me.

Ok.  Works for me, too.

Perhaps "There is ongoing work to allow servers to identify subscribers
initiating connections, to facilitate tracability and blocking of 
subscribers abusing a service (e.g., DoS attacks).  A future 
version of this specification is expected to recommend using
one of these mechanisms."

> charter of BEHAVE or not?

I believe so, but it's probably somewhere between BEHAVE and INTAREA.  

I'll add you to the BEHAVE agenda, because the audience in BEHAVE
should certainly be(come) aware of this issue.
http://www.ietf.org/proceedings/80/agenda/behave.html

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 13:41:41 -0400

This seems another incarnation of the 'log' problem.

BTW, it is not clear to me that "A future
 version of this specification is expected to recommend using
 one of these mechanisms."

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 13:41:51 -0400

On 3/15/11 9:47 AM, "[email-masked]"
<[email-masked]> wrote:

> * a user won't be impacted by a misbehaving action of another user sharing the
> same IP address. See
> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01#sect
> ion-1 for more details.

I think the solution does not fit the problem. Can you elaborate on an
actual use case from the top?

> * a service provider won't receive calls to hot-lines (OPEX reduction)

It will not receive calls or it will receive calls but will have more
information to go with them?

The identify of the user can be determined by the ISP through NAT logs based
on public source IP, port alone. Any action by the ISP will need to be done
on the private side anyway where there is a 'stable' IP address.

> * content providers: service experience.

Service experience to the content provider or the subscriber? Can you
elaborate in a little more detail how subscribers will benefit from this?

BTW, I'm not really opposed to this at this point to this but it is not
clear to me what exactly we are trying to solve and for which purpose.

"1.1.  Problem to Be Solved

   Observation: Today, servers use the source IPv4 address as an
   identifier to treat some incoming connections differently."

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 10:59:36 -0700

> Behalf Of Reinaldo Penno
> Sent: Tuesday, March 15, 2011 8:46 AM
> To: Simon Perreault; [email-masked]
> Cc: 'behave' <([email-masked])>; draft-ietf-behave-lsn-
> [email-masked]
> Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT
> 
> performance issues, amongst others. Not to mention that there are some
> 6 different techniques.

I agree with all your points except 'subscriber privacy issues'.

Subscribers, today, generally have publicly-routable IPv4 addresses.  
Those subscribers disclose their IP address every time they connect
to a website -- it's in the source IP address field of the IP header.
All of the techniques preserve that same information, in the face
of a CGN.

-d

> CGN
> >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-
> analysis-01
> >> analyzes
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 11:03:36 -0700

> Sent: Tuesday, March 15, 2011 9:12 AM
> To: [email-masked]; Simon Perreault

It benefits anyone who is operating a server -- today -- that is 
throttling connections from certain IP addresses due to abuse.
If both users and abusers are sharing the same IPv4 address,
the server cannot differentiate between the user and the abuser,
and will have to degrade service to legitimate users.  

If you run an ssh server on port 22 on the Internet, you are
undoubtedly familiar with tools such as DenyHosts, Banshee,
SSHblock, and other similar tools.  Those are examples of
these sorts of problems and deployed solutions, at a small
scale.

-d

> >>> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-
> issues-05
> >>> for
> >>> more details).
> >>>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 11:11:42 -0700

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 10:42 AM
> To: Dan Wing; [email-masked]; draft-ietf-behave-
> [email-masked]
> Cc: [email-masked]

No.  It's quite different.  Knowing your IP address is 
fe80::c126:c633:d2dc:8090 (according to your SMTP headers) 
doesn't tell me if someone else has acquired that IP address
between when you last used it and a minute in the future.   
Only the entity that hands out your IP address could know that
(e.g., your DHCPv6 server or something monitoring SLAAC).

-d

---

From: Tina Tsou <[email-masked]>
Date: Tue, 15 Mar 2011 11:29:11 -0700

A related I-D:
https://datatracker.ietf.org/doc/draft-chen-intarea-v4-uid-header-option/

IPv4 Header Option for User Identification in CGN Scenario

My co-authors are currently doing tests on
draft-chen-intarea-v4-uid-header-option.

After the test, we may have more input.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan Wing
Sent: Tuesday, March 15, 2011 11:00 AM
To: 'Reinaldo Penno'; 'Simon Perreault';
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT

-d

> issues-05 for

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 14:26:34 -0400

> (e.g., your DHCPv6 server or something monitoring SLAAC).

Isn't this the same problem you were actively discussing on the PCP list:
renumbering.  Renumbering already exists today and can not be solved by what
the document proposes (conveying the private IP address, because it might
have changed). A public IP can also be reused and the 'server' will not
know, only the ISP.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 11:46:28 -0700

> Sent: Tuesday, March 15, 2011 11:27 AM

Yes, the subscriber can be renumbered today -- and they are renumbered
today.

Subscribers will be renumbered tomorrow.

Yes, renumbering will cause some IP addresses to continue to have a
"poor reputation" for some-amount-of-time after the abuser was using
the address.  All of these existing systems time out those addresses.

The same is true of credit scores in real life, scary parts of town
(which are cleaned up with additional police presence), and a lot 
of other things.

The alternative is that everyone sharing the same IPv4 address be
put into the same low-quality of service, such as throttling all
of their activity, challenging them all with captchas, or blocking
them outright.

People will argue that ruining the IPv4 Internet will create an
incentive for people and content providers to move to IPv6.  
Which is true.  However, ruining the IPv4 Internet harms the
ISP's business and the content provider's business.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 15:06:40 -0400

But there are operational solutions for this problem which do not need
man-in-the-middle rewrite.

The abusers can be put in special public pool of address that is there for
such sole purpose. BTW, this already done today in many different forms.

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 15 Mar 2011 14:25:35 -0500

> I'll definitely need WG feedback on this.

I agree that user-hint would be a valuable feature for a CGN.  But it is not
a requirement for the successful operation of a CGN, and should not be
included in the requirements document.

Further, while I respect the analysis done in draft-boucadair-..., I don't
yet think there is consensus on the user-hint technology.  It would be
inappropriate to pick one approach at this time, pending more operational
experience and feedback.

Cheers,
-Benson

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 14:29:37 -0700

> Sent: Tuesday, March 15, 2011 12:07 PM
> The abusers can be put in special public pool of address that is there
> for such sole purpose.

For that, the ISP would decide which of their subscribers is abusive??

-d

> BTW, this already done today in many different
> forms.
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 14:50:08 -0700

> analysis-01#sect

Today, AT&T Mobility runs a NAPT44.  Occasionally I have 
been challanged with a captcha (*) while on my iPhone.  
See attached.  It's a real problem, today.  "Tomorrow,"
there will be more IPv4 address sharing until both clients
and servers are running IPv6.

The intent of user-hint is to provide content providers with 
additional information so that they can reduce the need for such 
heavy-handed mechanisms (such as captchas, such as connection-per-
minute throttling), and instead just throttle abusers while allowing
users through -- much as they are doing, today, with IPv4 addresses.

I hope that makes it clearer that this is not the "logging 
problem".  No amount of logging would change or prevent
the captcha challange.  Including a "user-hint" _can_ be
used by the content provider -- if they wish -- to 
differentiate between abusers and users.  This is important
for TLS services, as well, where the server burns CPU
before it realizes it just finished a TLS connection to
an abuser.

(*) http://en.wikipedia.org/wiki/CAPTCHA

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 18:13:23 -0400

There is a premise of stopping spam, abuse, etc. I'm assuming other ISP and
content providers will be contacting the ISP which hosts the attacker and
reporting the public IP address and source port (as required by a recent
draft). The ISP would then investigate and take appropriate action.

Are saying the Content Providers will take sole action and have a long list
of public IP<->private IP in their servers (or routers)? Can you elaborate
Providers will operationalize using the private IP inside those connections
to filter anything? A

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 15:27:31 -0700

> Sent: Tuesday, March 15, 2011 3:13 PM
> reporting the public IP address and source port (as required by a
> recent draft). 

I am not familiar with that draft.  But that would still be "the
logging problem", which is not the purpose or value of user-hint.

If the content provider is going to automatically (or manually)
contact the ISP, they can do that via existing means -- such as
by telling the ISP the source IP address, source port number, and
time of the abusive user's connection to their server.  That _is_
the "logging problem".  

> The ISP would then investigate and take appropriate action.
> 
> Are saying the Content Providers will take sole action and have a long
> list of public IP<->private IP in their servers (or routers)? 

They have long lists of this, today.  One (of many) examples are
the DNS blackhole lists operated by various organizations.  Another
example is the Cisco Ironport SenderBase, http://www.senderbase.org

And on a server that I help operate, we have a couple thousand
IP addresses in our /etc/hosts.denied file -- those are the 
IP addresses that have attempted dictionary attacks against
SSH, IMAPS, and other services.

> Can you elaborate
> Providers will operationalize using the private IP inside those
> connections to filter anything? A

To provide service to users while throttling/captcha'ing/denying
service to abusers.  The alternative is to throttle/captcha/deny
service to the entire source IP address -- which harms 
legitimate users.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 18:54:59 -0400

On 3/15/11 3:27 PM, "Dan Wing" <[email-masked]> wrote:

> the DNS blackhole lists operated by various organizations.

So is one of the requirements that such blacklisted zone transfers have
public IP<-> private IP mappings?

> Another

Will the TCP stack be checking for the embedded private IP?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 16:03:11 -0700

> Sent: Tuesday, March 15, 2011 3:55 PM

Not at all.

It needs 'public IP + something_that_differentiates_user_from_abuser'.
The public IP is the source IP address, which we are all familiar with
using.  The differentiator is the key part when doing address sharing.

That differentiator does _not_ need to be the user's private IP
address.  It could be their social security number (kidding),
a portion of their internal IP address (e.g., 24 bits of their
IPv4 address), their VLAN number, the first 8/12/16 bits of a hash 
of their internal IP address, or a dozen other ideas that are
easy to craft up on a napkin.

> Will the TCP stack be checking for the embedded private IP?

If they want to use the additional information, yes.

-d

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 08:47:37 +0100

Hi Reinaldo,

Yes this may work but the operator needs to identify the abuser before...which is not easy.

The issues are discussed in detail in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05. In Section 13.1 you can read for instance:

   In addition, there are web tie-ins into different blacklists that web
   administrators subscribe to redirect users with infected machines
   (e.g., detect the presence of a worm) to a URL that says "Hey, your
   machine is infected!".  With address sharing, someone else's worm can
   interfere with the ability to access the service for other
   subscribers sharing the same IP address.

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 08:58:10 +0100

Re-,

The problem is that due to address sharing, users may experience service degradation and troubles to access to some services because:

* Content Providers may rely on the source IP address as simple implicit authentication
* Content providers rely on the source IP address to blacklist misbehaving users
* infected users are redirected to dedicated URL based on there IP address
* See http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for an exhaustive list of issues.

To avoid all users sharing the same IP address be impacted, an ID in addition to the source IP address is needed to uniquely distinguish a user among those sharing the same IP address. In nat-reveal-analysis I-D, we wrote:

"The server must have extra information than the source
   IP address to differentiate the sending host.  We call USER_HINT this
   information.

   o  What is the USER_HINT?  It must be unique to each user under the
      same address.  It does not need to be globally unique.  Of course,
      the combination of the (public) IPv4 source address and the
      identifier ends up being relatively unique.  As unique as today's
      32-bit IPv4 addresses which, today, can change when a user re-
      connects."

Hope the problem is more clear.

Cheers,
Med

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 11:03:28 -0400

> I'll definitely need WG feedback on this.

Ok there seems to be consensus that there is a problem but that the
solution space is not clear enough to make a requirement.

So I think what is appropriate at this point is to reference ongoing work.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 17:17:22 +0100

In your previous mail you wrote:

   Ok there seems to be consensus that there is a problem

=> I have a real question about who the problem is for.
I don't believe users want extra mechanisms to track their
activity, in particular I am afraid of the consequences
of an IETF action decicated to reduce user privacy,
or something which can give this feeling.

So IMHO we should be very careful here. For instance
active mechanisms should not be preferred without a good
argument.

Thanks

[email-masked]

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 17:30:32 +0100

Francis,

The user_hint we are talking about is similar to the source IPv4 address when there is no NAT. 

As described in http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01#section-1:

   Observation: Today, servers use the source IPv4 address as an
   identifier to treat some incoming connections differently.  Tomorrow,
   due to the introduction of CGNs (e.g., NAT44, NAT64), that address
   will be shared.  In particular, when a server receives packets from
   the same source address.  Because this address is shared, the server
   does not know which host is the sending host.

   Objective: The server should be able to sort out the packets by
   sending host.

   Requirement: The server must have extra information than the source
   IP address to differentiate the sending host.  We call USER_HINT this
   information.

      connects.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mercredi 16 mars 2011 17:17
À : Simon Perreault
Cc : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 17:59:44 +0100

The user_hint we are talking about is similar to the source IPv4
   address when there is no NAT.
   
=> I know but NATs are considered as security devices by some people
and here you remove this capability. And the technical arguments
are not enough, what matters is the feeling some people have.

BTW we had already a similar issue with IPv6 addressing and
technically the USER_HINT seems to be a HOST_HINT: this is bad
because it would give an advantage to NAT444 over DS-Lite as
NAT444 includes a first NAT44 level which "hides" the HOST
and reveals only the USER. Another reason to be careful...

Thanks

PS: BTW is BEHAVE chartered to discuss about this, IMHO it is clearly
in the INTAREA scope (and authors of the proposal share this opinion
according to the name of the draft).
Perhaps the best will be to wait for a resolution by INTAREA,
i.e., jump far from this in place of into this.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 16 Mar 2011 13:38:11 -0400

Thanks. This text is much better and clearer. Anybody without context will
hit the ground running.

On 3/16/11 12:58 AM, "[email-masked]"
<[email-masked]> wrote:

> Re-,
> 
> The problem is that due to address sharing, users may experience service
> degradation and troubles to access to some services because:
> 
> * See 
> an exhaustive list of issues.
> 
> To avoid all users sharing the same IP address be impacted, an ID in addition
> to the source IP address is needed to uniquely distinguish a user among those
> sharing the same IP address. In nat-reveal-analysis I-D, we wrote:
> 
http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01#sec>>
t

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 17 Mar 2011 16:18:58 -0500

> are not enough, what matters is the feeling some people have.

I think the user-hint feature may sometimes be desired, but also may be
undesired as Francis describes.  The user-hint feature is not an appropriate
requirement, unless it's specified as a MAY.

Cheers,
-Benson