[Dshield] Need some help testing

[Tomas L. Byrnes]

I'm not even sure what points you are trying to make, so I will try to
address the ones I think you are, and give my responses:

Are you saying that "dynamic" IP filtering is widespread? If so, I
agree. 

Are you saying that blocking SMTP traffic from "Dynamic" IP addresses is
a best practice? If so, based on direct personal experience, I disagree
vehemently. While, in theory, no-one should have a truly dynamic IP
address as an MX or SMTP peer, the extant lists of what constitutes
"Dynamic" address space are, in my direct experience and NSHO, wildly
inaccurate. As such, since there is no way, in the current Internet, to
really know if an IP is static or dynamic, blocking "Dynamic" IP
addresses exacerbates the "Scorched Earth" problem of traditional RBLs,
for a limited net gain in SPAM filtering.

Are you saying that there should be some consensus as to what
constitutes a "dynamic" IP, and that ISPs should have a way that is a
best practice for designating what IPs are static versus dynamic? If so,
once again, I agree. I feel, however, that the adoption and
implementation of such a practice will take time, and that high-handed
application of a draft spec to force people to adapt to it is totally
counter to the traditional IETF process of "Rough Consensus and running
code".

Are you saying that the method proposed in the draft RFC is a good way
of propagating dynamic versus not? I demur. I need to examine the spec
more closely, as opposed to relying on your selective quoting and
interpretation.

Are you saying your interpretation of the draft RFC is an accurate
interpretation of the drafters' intent, and accurately identifies
dynamic IPs while excluding static ones? I disagree vehemently.

So, in summary, I think the underlying premise of your proposed method:
that whether an IP address is dynamically assigned or not, and that that
dynamic assignment has entropy (meaning it isn't effectively persistent
for the length of the subscribers subscription), is easily discernible
from the PTR records, is demonstrably false for a large percentage of
the IPV4 space, and that filtering on that basis is an effective denial
of service.

I have BCC'd my friend and mentor, Paul Mockapetris, the author of the
DNS. If he responds to this, I will forward it, redacted of his personal
e-mail address.


 

> -----Original Message-----
> From: list-bounces at lists.dshield.org 
> [mailto:list-bounces at lists.dshield.org] On Behalf Of Mar 
> Matthias Darin
> Sent: Sunday, July 08, 2007 11:26 AM
> To: General DShield Discussion List
> Subject: Re: [Dshield] Need some help testing
> 
> Hello, 
> 
> Tomas L. Byrnes writes: 
> 
> > If you use drafts for public connectivity, you are asking 
> for trouble.
> > What you propose is akin to trying to run OSPF and/or BGP with all 
> > connected peers, and not accepting traffic from those that don't 
> > provide you routing information via those methods.
> > 
> > PTR records are created for many reasons, and in many cases 
> have been 
> > around a lot longer than the drafts you reference or their 
> > predecessors, and are usually used by the OSS/NMS systems for node 
> > identification, so changing them is a non-trivial exercise.
> > 
> > IMNSHO, your approach has a very high probability of false 
> positives.
> 
> Remember, this is already is practice.  The IETF draft is 
> simply attempting to formalize the process.  With or without 
> the draft, the practical applicate of dynamic IP address 
> filtering is not going to stop. 
> 
> Surprisingly, the number of false positives is quite low.  In 
> the 8 years of my research, I have encountered 5 false 
> positives, though it must be stated that each machine will 
> have different stats.  DynaStop takes into account this and 
> provides an easy method for exclusions. 
> 
> Again true, however, the laws of probability still hold true 
> that a vast number (last estimate was 2/3) of the Internet 
> does not change in a rapid fashion.  All too often, standards 
> are based on common practices of which are usually not the 
> best.  The Internet is filled with many cases of this, SMTP 
> is just one example.
> _________________________________________
> SANSFIRE 2007 July 25-August 2 in Washington, DC.  56 
> courses, SANS top instructors, and a great tools and 
> solutions expo. Register today!
> http://www.sans.org/info/4651 (brochure code ISC)
>