Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02

From: "Dan Wing" <[email-masked]>
Date: Mon, 6 Aug 2012 17:29:27 -0700

> -----Original Message-----
> From: Wesley Eddy [mailto:[email-masked]]
> Sent: Saturday, July 28, 2012 12:28 AM
> To: Dan Wing
> Cc: [email-masked]; 'Internet Area'; 'Behcet Sarikaya'
> Subject: Re: [Int-area] Completion of working group last call for
> draft-ietf-intarea-nat-reveal-analysis-02
> 
> On 7/27/2012 2:03 PM, Dan Wing wrote:
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> On
> >> Behalf Of Wesley Eddy
> >> Sent: Thursday, July 26, 2012 11:34 AM
> >> To: [email-masked]
> >> Cc: Internet Area; Behcet Sarikaya
> >> Subject: Re: [Int-area] Completion of working group last call for
> >> draft-ietf-intarea-nat-reveal-analysis-02
> >>
> >> On 7/26/2012 1:08 PM, Behcet Sarikaya wrote:
> >>> On Thu, Jul 26, 2012 at 3:25 AM,  <[email-masked]>
> >> wrote:
> >>>> Dear Suresh, all,
> >>>>
> >>>> After reading received comments, the major point we need to
> discuss
> >> is whether the WG wants to remove Section 3.3 or maintain it. I'm
> >> waiting for a feedback from the WG for the direction to take. I will
> >> implement any change requested by the WG.
> >>>>
> >>>
> >>> Section 3.3 seems to give preference to one specific solution, as
> >> such
> >>> it is against the whole spirit of this document.
> >>>
> >>> I suggest removing it.
> >>>
> >>
> >>
> >> +1
> >>
> >> In fact, I suggest that the draft should clearly say that it's
> >> doubtful whether a solution actually *needs* to be identified and
> >> recommended, especially ones that are implemented awkwardly in other
> >> layers.
> >
> > I can't make technical sense of which of the 8 approaches are
> "awkward," in
> > your analysis.  I have my own analysis, but the document does not do
> an
> > evaluation on "awkwardness".
> >
> >
> > The underlying problem was identified in Section 13.1 "Abuse Logging
> and
> > Penalty Boxes" of RFC6269, "Issues with IP Address Sharing",
> > http://tools.ietf.org/html/rfc6269#section-13.1.  That was an INTAREA
> > document.
> >
> > Hence, that is why the analysis document is also an INTAREA document.
> >
> >
> > My view is the penalty box problem described in Section 13.1 of
> RFC6269 is
> > real.  My view is the penalty box problem will continue to grow so
> long as
> > there are IPv4-accessible servers and so long as there are IPv6
> clients
> > (NAT64) or IPv4 clients accessing those IPv4 servers.  There appear
> to be
> > different views on the size and trajectory of the problem (getting
> worse
> > versus getting better).  Perhaps discussing those views would be
> beneficial.
> >
> 
> 
> Hi Dan - The problem is real because there are bits of
> deployed code built on an assumption that was good maybe
> 12 years ago, that IP addresses could be tied to users or
> machines.  Since this is totally broken now, the solution
> is to get rid of them and use the proper identifiers for
> whatever it is that these system are trying to do. 

During the INTAREA presentation, one suggestion I heard was
a separate protocol (ident-like).  I will submit an I-D towards
that end, which I am dusting off from 2010 when I first 
considered ident and discarded it for a variety of reasons.

Do you have additional suggestions on how to accomplish convey
an identifer?

> Building
> kludges in other layers to supplement the IP address is
> not the answer.

We do have a long history of crossing layers, as much as we
pretend we don't do that -- ARP, IPv6 changing UDP checksum
requirements compared to IPv4, incorporation of IP addresses
for referrals in dozens of protocols (partially due to lack of
a name service).

> Since the analysis in the document already indicates that
> each of the 8 solutions has non-starter properties to them,
> I consider that to make them pretty "awkward".  Recommending
> any of them is like saying "this is the best tasting crap
> we could find."

Yeah, awkwardness happens a lot with address sharing.  I also 
wish it was different.

-d

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 Aug 2012 07:49:57 -0700

On Aug 6, 2012, at 5:29 PM, Dan Wing wrote:

> ...

There are two separate problems:

- establishing an identity and pairing it with a tag

- getting that tag into connections so each connection can be correlated back to the identity

This draft focuses on the second step. The first is either trivial (with cooperating entities) or needs to be inferred if possible (with non-cooperating/legacy entities). It doesn't matter whether the entity is a person or a machine in general, though this draft focuses on machine entities.

Any out-of-band mechanism shares the fate of "ident" in this doc, as noted in Sec 5.9, though. Is there a point to generating another solution in that space?

Joe

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2012 11:02:16 -0400

> - getting that tag into connections so each connection can be correlated back to the identity

3) making sure that not everyone can associate the identity with that tag.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Aug 2012 08:30:51 -0700

> From: Scott Brim [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 8:02 AM
> To: Joe Touch
> Cc: Dan Wing; Internet Area; Behcet Sarikaya

Scott,

Today's Internet users, which are not sharing addresses with other users,
are sending an uniquely-identifyable identifier to every Internet server
they use:  their unique IP address.  

-d

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 Aug 2012 09:08:17 -0700

> 3) making sure that not everyone can associate the identity with that tag.

or forge it, etc. Yes, there are numerous conditions on the two steps above. I tend to think of these as steps (as above) and conditions on the steps.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 Aug 2012 09:09:39 -0700

> they use:  their unique IP address.  

Given how IP addresses are used today, an address alone is insufficient to indicate a host. That's the whole point of this doc.

Addresses and ports together sometimes do, but not in all cases. Other IDs are required - again, the conclusion of this doc.

Out-of-band IDs are problematic for many reasons, again as per Sec 5.9

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 08 Aug 2012 23:25:35 -0400

> they use:  their unique IP address.  

Users don't have IP addresses.  Machines do.  Which are
we trying to identify again?  I think the distinction
is important since the relation between users and devices
can be one-to-many, or many-to-one, and certainly isn't
one-to-one, even if we went back in time when the
relation between end-host machines and addresses might
have been closer to one-to-one.

I also don't think user and subscriber are synonyms for
many purposes, though some of the reveal-analysis seems to
be more oriented towards identifying the access network
subscriber.  That subscriber generally may have quite
a few users and machines behind them.

-- 
Wes Eddy
MTI Systems

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Aug 2012 10:07:08 -0700

> Sent: Wednesday, August 08, 2012 8:26 PM
> To: Dan Wing
> Cc: 'Scott Brim'; 'Joe Touch'; 'Internet Area'; 'Behcet Sarikaya'
> subscriber.  

RFC6269 section 13.1 mixes the term 'subscriber' itself:

   When an abuse is reported today, it is usually done in the form: IPv4
   address X has done something bad at time T0.  This is not enough
   information to uniquely identify the subscriber responsible for the
........................................^^^^^^^^^^
   abuse when that IPv4 address is shared by more than one subscriber.
...........................................................^^^^^^^^^^

   Second and more likely is that one user who fails a number of login 
......................................^^^^
   attempts may block out other users who have not made any previous 
................................^^^^^
   attempts but who will now fail on their first attempt.

> That subscriber generally may have quite a few users 
> and machines behind them.

draft-ietf-intarea-nat-reveal-analysis is not analyzing that problem.

Today's IP address penalty boxes do not attempt to distinguish
between the hacker son at home doing a dictionary attack against
a mailserver and the mom trying to legitimately login to that
same mailserver.  The mailserver will protect itself from the
dictionary attack by putting that offending IP address into a
penalty box.  

The different problem that draft-ietf-intarea-nat-reveal-analysis is
analyzing is when multiple subscribers can no longer be individually 
identified by their IP address because of IP address sharing.  This
means the hacker son (in the scenario in the previous paragraph) can
now deny service to everyone else sharing that same IP address, which
could be dozens or hundreds of subscribers.

We might replace 'hacker son' with 'compromised host'.

-d