Repeated Blacklisting / IP reputation

Wed Sep 16 02:29:16 UTC 2009

On Tue, Sep 15, 2009 at 09:34:14PM -0400, Christopher Morrow wrote:
> On Tue, Sep 15, 2009 at 4:46 PM,  <bmanning at vacation.karoshi.com> wrote:
> >
> > so... this thread has a couple of really interesting characteristics.
> > a couple are worth mentioning more directly (they have been alluded to elsewhere)...
> 
> as always, despite your choice in floral patterned shirts :) good
> comments/questions.

	humph... at least I wear pants.

> >
> >        Who gets to define "bad" - other than a blacklist operator?
> >        Are the common, consistent defintions of "contamination"?
> 
> nope, each BL (as near as I can tell) has their own criteria (with

	trick question... each ISP gets to define good/bad on their
	own merits or can outsource it to third parties.


> 1) newly allocated from IANA netblocks show up to end customers and
> reachability problems ensue. (route-filters and/or firewall filters)
> 
> 2) newly re-allocated netblocks show up with RBL baggage (rbls and
> smtp blocks at the application layer)

	you forgot #3 ... a "clean" IANA block that was "borrowed"
	for a while .. and already shows up in some filter lists.


> > So - I suspect that in the end, a registry (ARIN) or an ISP (COMCAST) is only
> > going to be able to tell you a few things about the prefix you have been handed.
> >
> >        a) its virginal - never been used (that we know of)
> >        b) its been used once.
> >        c) it has a checkered past
> 
> I actually don't think it's a help for ARIN to say anything here,
> since they can never know all the RBL's and history for a netblock,
> and they can't help in the virginal case since they don't run
> network-wide filters.

	not RBL specific ...  

	a) this block came directly from IANA and has never been previously allocated
	   in/through the IANA/RIR process
	b) this block has had one registered steward in recorded history
	c) this block has been in/out of the RIR/registry system more than once.

> A FAQ that says some of the above with some pointers to testing
> harnesses to use may be useful. Some tools for network operators to
> use in updating things in a timely fashion may be useful.
> Better/wider/louder notification 'services' for new block allocations
> from IANA -> RIR's may be useful.

	indeed - I'd like to see the suite extended to the ISPs as well, esp
	if such tricks will be used in v6land...

> last announced APNIC block yahtzee.  Where else is this data
> available? In a form that your avg enterprise network op may notice?

	oh... I'd suggest some of the security lists might be a good
	channel.

> > and it will be up to the receipient to trust/accept the resource for what it
> > currently is or chose to reject it and find soliace elsewhere.
> 
> 'solace elsewhere'... dude there is no 'elsewhere'.

	and yet... Jimmy and Warren Buffet will tell you its always 1700 somewhere....
	and if that doesn't work,  whip out the NAT and reuse 10.0.0.0 -again-.... :)


> 
> -Chris
> (and yes, I'm yanking your chain about the shirts...)
> 
> > --bill
> >
> >
> > On Tue, Sep 15, 2009 at 04:31:04PM -0400, Christopher Morrow wrote:
> >> On Tue, Sep 15, 2009 at 4:23 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> >> > On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
> >> >
> >> >>   Anyone that intentionally uses address space in a manner that they
> >> >> know will cause it to become contaminated should be denied on any
> >> >> further address space requests.
> >> >
> >> > You *do* realize that the people you're directing that paragraph at are
> >> > able to say with a totally straight face: "We're doing nothing wrong and
> >> > we have *no* idea why we end up in so many local block lists"?
> >>
> >> Also, you can very well disable new allocations to Spammer-Bob, did
> >> you also know his friend Sue is asking now for space? Sue is very
> >> nice, she even has cookies... oh damn after we allocated to her we
> >> found out she's spamming :(
> >>
> >> Spammers have a lot of variables to change in this equation, RIR's
> >> dont always have the ability to see all of the variables, nor
> >> correlate all of the changes they see :(
> >>
> >> -Chris
> >>
> >