[121173] in North American Network Operators' Group
Re: SORBS on autopilot?
daemon@ATHENA.MIT.EDU (Jed Smith)
Tue Jan 12 13:31:53 2010
From: Jed Smith <jed@jedsmith.org>
In-Reply-To: <20100112174258.GB9961@hesketh.com>
Date: Tue, 12 Jan 2010 13:31:06 -0500
To: Steven Champeon <schampeo@hesketh.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Steven, take it easy please.
Given the first few replies I received, allow me to clarify, now that =
I've
successfully hijacked the thread and apparently angered the anti-spam =
crowd:
I am quite aware of the problem and do not disagree that there needs to =
be a way
to identify what IP endpoints are residential CPE. I simply have some =
problems
with /this/ current incarnation of a best practice, and I was querying =
whether
it had applicability outside of the SORBS/Trend Micro world.
Honestly, I feel that PTRs are the least reliable way to make such a =
decision.
Depending on the chain of delegation, a server operator may not have =
access to
modify his PTR record and might not be able to change it. Several =
operators
have annoyingly odd delegation patterns. PTRs are just bad news for any =
kind of
useful decision on, other than "PTR-matches-A". Given the amount of IRC =
abuse
PTRs have seen, the consequential abuse of IPv4 allocation to support =
exotic
PTRs, and the resulting limitation of PTR alteration that many providers
practice I just don't like PTRs overall for anything meaningful.
I also disagree with space being assumed dynamic unless it is declared =
static --
helpfully, I have been reminded that consumer CPE equipment is a large =
number of
IPv4 endpoints, but I still think space should be assumed static unless
declared dynamic. The burden really should be upon the providers of =
dynamic
services to inform us that their allocations are a dynamic pool; good =
luck with
this, however.
Getting a standards-track solution that is reliable, cost-effective for =
home
Internet providers to get on board with, and that has very little =
wiggle-room
for discretion (this current incarnation has quite a bit) is necessary =
for me to
be on board with such classification techniques. That said, I am not =
the guru
that others on this list are and I am unprepared to present an =
alternative; I am
simply pointing out that I'd like to see an alternative.
Let me reiterate: I'm not disputing the challenges that network =
operators face
with network abuse, I am simply disagreeing with this draft, its =
authorship, the
sour taste you get from reading it because it's so far past expiration, =
and its
motives in current practice. It's akin to me disagreeing with daylight =
savings
time because it tries to fix energy consumption from lighting.
JS
