North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Clueless service restrictions (was RE: Anti-spam System Idea)

  • From: Tony Hain
  • Date: Tue Feb 17 19:22:02 2004

Alex Bligh wrote:
> Steve,
> --On 17 February 2004 17:28 -0500 "Steven M. Bellovin"
> <[email protected]> wrote:
> > In almost all circumstances, authentication is useful for one of two
> > things: authorization or retribution.  But who says you need
> > "authorization" to send email?  Authorized by whom?  On what criteria?
> Authorized by the recipient or some delegee thereof, using whatever
> algorithms and heuristics they chose. But based on data the authenticity
> of
> which they can determine without it being trivially forgeable, and without
> it being mixed up with the transport protocol. IE in much the same way as
> say PGP, or BGP.
> > Attempts to define "official" ISPs leads very quickly to the walled
> > garden model -- you have to be part of the club to be able to send mail
> > to its members, but the members themselves have to enforce good
> > behavior by their subscribers.
> I never said anything about "official" ISPs. I am attempting to draw an
> analogy (and note the difference) between SMTP as currently deployed, and
> the way this same problem has been solved many times for other well known
> protocols.

No it hasn't, and your comparison to BGP is very much about 'official ISPs'.
For starters your examples are not anywhere close to the same scale as the
SMTP 'problem', and are restricted to 'IN' players. The closest they get is
the blatant attempt to restrict SMTP to the privileged club of BGP speakers.

> We do not have an official BGP authorization repository. Or an official
> authorization repository. We just have people we chose to trust, and
> people
> they in turn chose to trust. 

Where they specifically form a club and agree to preclude the basement
multi-homed site from participating through prefix length filters. This is
exactly like the thread comments about preventing consumers from running
independent servers by forced filtering and routing through the ISP server.
This is not scaled trust; it is a plain and simple power grab. Central
censorship is what you are promoting, but you are trying to pass it off as
spam control through a provider based transitive trust structure. Either you
are clueless about where you are headed, or you think the consumers won't
care when you take their rights away. Either way this path is not good news
for the future Internet. 


> Take BGP (by which I mean eBGP) as the case in
> point: It seems to be general held opinion that the one-and-only canonical
> central repository for routes does not work well. The trust relationship
> is
> important, and we expect some transitivity (no pun intended) in the trust
> relationshipa to apply. And many end-users in the BGP case - i.e. stub
> networks - chose to "outsource" their their trust to their upstream; when
> they don't like how their upstream manages their routes, they move
> provider. BGP allows me (in commonly deployed form) to run a relatively
> secure protocol between peers, and deploy (almost) universal end-to-end
> connectivity for IP packets in a manner that does not necessarily involve
> end users in needing to know anything about it bar "if the routing doesn't
> work, I move providers"; and IP packets do not flow "through" BGP, they
> flow in manners prescribed by BGP. Replace BGP by "a mail authorization
> protocol" and "IP packets" by "emails" in the foregoing; if the statement
> still holds, we are getting there (without reverting to bangpaths &
> pathalias). Oh, and people keep mentioning settlement and how it might fix
> everything - people said the same about BGP (i.e. IP peering) - may be,
> may
> be not - the market seems to have come up with all sorts of ingenious
> solutions for BGP.
> Alex