Re: WANTED: ISPs with DDoS defense solutions

[Paul Vixie]

[EMAIL PROTECTED] ("Christopher L. Morrow") writes:

> There are many cases in which the backbone can't determine the 'proper'
> traffic an edge is sending in.

i'd like to discuss these, or see them discussed.  networks have edges,
even if some networks are "edge networks" and some are "backbone networks."
bcp38 talks about various kinds of "loose" rpf, for example not accepting
a source for which there's no corresponding nondefault route.

> Not to mention the problems of filtering on
> an edge device with 100's or 1000's of interfaces. The proper and simple
> place for this filtering  is as close to the end device as possible.
> Backbones just aren't made to filter traffic, edge networks are.

so, the problem is transitive.  you might have a multihomed customer whose
network spans some of the same peerography as yours, and if you both use
hot potato there will be path assymetry, such that your route back to a
source might be through pop A while they deliver that source's traffic to
you at pop B.  your only recourse is to get them to filter at their edge,
which you hope is less ambiguous than yours.

but they might have the same situation with their downstream.  and you're
not requiring them to do edge filtering as a contract/peering term, nor are
you requiring them to require their downstreams to do so.  this means the
problem goes from "transitive" to "laundered" in about one AS hop or so.  i
don't consider this a healthy situation, and i'd like to hear you list
the kinds of rpf you know of and why none can be used on a "backbone".
-- 
Paul Vixie

Re: Humidity ranges?

[Jeff Kell]

Todd Mitchell - lists wrote:

| and when I should
| complain to the datacenter operators? (References I can point to would
| be nice.)
When your equipment starts to rust ;)

I don't have any technical references, but I think that anything over
65% is probably too much.  Most facilities I have equipment in do not
exceed that mark.
It isn't a *huge* issue (within reason) unless you have printers around 
and the inherent paper.  Big lasers are notoriously finicky about 
humidity, which directly affects the paper quality.

Otherwise, just keep it well below the dewpoint :-)

Jeff

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Henry Linneweh]

Here is a company who thinks they have a solution for spam
http://www.nwtechusa.com/ironmail-zd-srit-enterprise-security.html
 
-Henry[EMAIL PROTECTED] wrote:

> I would have though people would have learned by now that > there is no technical solution to spam. You can go ahead> with all these wonderfully expensive > authentication/filtration/insertantispambuzzword systems until > the cows come home and you will +_still_+ recieve spam. > > Regards,> Neil.And so we should do nothing?

Re: WANTED: ISPs with DDoS defense solutions

[Christopher L. Morrow]

On Mon, 4 Aug 2003, Jack Bates wrote:

>
> Randy Bush wrote:
> >>anti-spoofing eliminates certain avenues of attack allowing one to focus
> >>on remaining avenues, and hence (as Vix stated) is necessary but not
> >>sufficient.
> >
> >
> > it turns 1% of the technical problem into a massive social business
> > problem which, even if it was solvable (which it practically isn't),
> > would also be addressed by technical solutions where no spoofing is
> > involved.
> >
> Spoofed packets are harder to trace to the source than non-spoofed
> packets. Knowing where a malicious packet is very important to the

this is patently incorrect: www.secsup.org/Tracking/ has some information
you might want to review. Tracking spoofed attacks is infact EASIER than
non-spoofed attacks, especially if your network has a large 'edge'.

Re: Humidity ranges?

[Marshall Eubanks]

On Mon, 04 Aug 2003 23:35:24 -0400
 Jeff Kell <[EMAIL PROTECTED]> wrote:
> 
> Todd Mitchell - lists wrote:
> 
> > | and when I should
> > | complain to the datacenter operators? (References I can point to would
> > | be nice.)
> > 
> > When your equipment starts to rust ;)
> > 
> > I don't have any technical references, but I think that anything over
> > 65% is probably too much.  Most facilities I have equipment in do not
> > exceed that mark.
> 
> It isn't a *huge* issue (within reason) unless you have printers around 
> and the inherent paper.  Big lasers are notoriously finicky about 
> humidity, which directly affects the paper quality.
> 

If you are running lots of mag tape, humidity > 60 % starts to really
increase tape and head wear. If new tape heads are part of your
regular operating budget, I would keep the humidity < 50 %.

Regards
Marshall Eubanks

> Otherwise, just keep it well below the dewpoint :-)
> 
> Jeff
> 

Re: Edge 1 Networks/Williams Communications Group

[Booth, Michael (ENG)]

> After several run-ins with Edge 1 Networks [69.44.28.0/22] having their 
> machines "hijack" victim machines on our networks infected with Jeem, 
> and then making their spam runs, I've had it.  I have reported both to 
> Edge 1 and their parent Williams Communications Group [AS7911] with no 
> result and I will be blocking Edge 1 [in theory, AS29986, but no doubt 
> private spewage from WCG.NET).

I smell a rat.  I have a funny feeling Edge1 is a front for
pro-spammer Nick Geyer.

Look at their whois:

  Edge1 Networks
  Hostmaster Edge1
  25 Broadway - 5th Floor
  New York, NY 10004
  US
  Phone: 212-248-1121
  Fax..: 212-248-0929

But if you call Verizon, they'll tell you these lines terminate
on the sixth floor of 25 Broadway, an address I remember all
too well from the VMX Networks hijackings.

If you want the abuse to stop, call Nick at work (212-685-2009)
or on his cellular phone (503-851-1963) and tell him to knock it off.

If Nick is busy or at a meeting, as is often the case
ask to speak to his boss, Paul Hodara, and see if he can track
him down.

The Williams NOC could care less, if you want to get anywhere,
try contacting Blake Williams ([EMAIL PROTECTED]) or 
Michael Winslow ([EMAIL PROTECTED]), who are capable of
taking action, including ultimately denying service to Edge1 
for AUP violations.

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Paul Vixie]

[EMAIL PROTECTED] writes:

> And so we should do nothing?

of course not.  but the first thing to do is "ignore naysayers".  anybody
who tells you something can't be done should be suspected of extreme and
pervasive laziness until either they or you prove otherwise.
-- 
Paul Vixie

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[E.B. Dreger]

> Date: Mon, 4 Aug 2003 18:50:36 -0400 (EDT)
> From: [EMAIL PROTECTED]


> And so we should do nothing?

If a _few_ networks null-route abusers, said networks isolate
themselves.  If _all_ networks cut off abusers, who becomes the
island?

Fixing the Internet is difficult.  What can't be tackled
overnight isn't worth the effort.  Let's leave it to future
generations.  (At least we all feel a bit better each time after
we gripe on nanog.)


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

Re: WANTED: ISPs with DDoS defense solutions

[Rob Thomas]

Hi, NANOGers.

]   For those of you that are doing IPv6 deployments, might I suggest
] you also take the time to do the same?  I know that Cisco has v6 u-rpf
] support already.

It's "shameless plug and solicitation of feedback day" here at Team
Cymru.  :)  We have put together a very rough beta of an IPv6 bogon
page.  We could really use some feedback, suggestions, and witty
comments.  You will find the BETA page at the following URL:

   

The long-term goal is to provide this data in the same manner that
we provide the IPv4 data, e.g. through HTML, text, DNS, and BGP
peering.

Thanks!
Rob, for Team Cymru.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: WANTED: ISPs with DDoS defense solutions

[Rob Thomas]

Hi, NANOGers.

] Also, if you can't do it everywhere, doing it where you _can_ is preferable to
] not doing anything at all.

Indeed, every little bit helps.  We will win these battles by
degrees, folks, not through a single panacea.  So, with that
said, I have to make a shameless plug for the Bogon Page.  It
makes filtering reasonably easy and automated.  If there is
something else we at Team Cymru can do to help you filter out
the nasty packets, please don't hesitate to ask!

   

I am on a soapbox, but that's because I'm short.  :)

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: WANTED: ISPs with DDoS defense solutions

[bdragon]

>   it all comes down to filtering, filtering, filtering.
> 
>   announcement filtering, anti-spoof filtering, peer filtering.
> 
>   If you're not doing this, you *SHOULD* be.  I know it's hard
> to do these things in the current business environment.  Those of
> you that can, please take the time to do this.  It will make the lives
> of the rest of us much easier when tracing attacks back.

Also, if you can't do it everywhere, doing it where you _can_ is preferable to
not doing anything at all.

-- 
BD.

Re: WANTED: ISPs with DDoS defense solutions

[Jared Mauch]

On Mon, Aug 04, 2003 at 04:59:53PM -0500, Jack Bates wrote:
> on has to contact each IP owner and find out if spoof protection is 
> enabled.

it's worse than that.  If they have it enabled (eg: 10.0.0.0/24 has
it enabled), but nobody else does, it allows everyone else to spoof
from the 10/24 prefix causing large sets of complaints to filter into
their mailbox.

If we're able to authenticate the sources, then we can presume
abuse reports are authentic.  (aside from address space hijacking issues).

it all comes down to filtering, filtering, filtering.

announcement filtering, anti-spoof filtering, peer filtering.

If you're not doing this, you *SHOULD* be.  I know it's hard
to do these things in the current business environment.  Those of
you that can, please take the time to do this.  It will make the lives
of the rest of us much easier when tracing attacks back.

For those of you that are doing IPv6 deployments, might I suggest
you also take the time to do the same?  I know that Cisco has v6 u-rpf
support already.

- Jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: WANTED: ISPs with DDoS defense solutions

[bdragon]

> On Mon, Aug 04, 2003 at 05:28:07PM -0400, [EMAIL PROTECTED] wrote:
> > 
> > > I'm all for raising the bar on attackers and having end networks implement
> > > proper source filtering, but even with that 1000 nt machines pinging 2
> > > packet per second is still enough to destroy a T1 customer, and likely
> > > with 1500 byte packets a T3 customer as well. You can't stop this without
> > > addressing the host security problem...
> > 
> > Do you believe backbone networks should do nothing?
> 
>   I'm not sure what you are saying here, backbones do do
> something, the problem is that it's easy to fill up a T1.  *really* easy.

I was asking about Chris's use of "having end networks implement
proper source filtering" implying that backbones should not do so.

Re: WANTED: ISPs with DDoS defense solutions

[bdragon]

>  Filtering the bogons does help, and everyone should perform anti-spoofing
>  in the appropriate places.  It isn't, however, a silver bullet.
> >>> it's necessary but not sufficient.
> >> anti-spoofing is useful, but vastly insufficient, and hence not necessary
> > anti-spoofing eliminates certain avenues of attack allowing one to focus
> > on remaining avenues, and hence (as Vix stated) is necessary but not
> > sufficient.
> 
> it turns 1% of the technical problem into a massive social business
> problem which, even if it was solvable (which it practically isn't),
> would also be addressed by technical solutions where no spoofing is
> involved.
> 
> but it would provide a lot of fun and soapboxes for wannabe net
> police and vigilantes.
> 
> randy

What is your solution which addresses the 100%? 99%? 50%?

What problems does anti-spoofing create?

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[bdragon]

> I would have though people would have learned by now that 
> there is no technical solution to spam. You can go ahead
> with all these wonderfully expensive 
> authentication/filtration/insertantispambuzzword systems until 
> the cows come home and you will +_still_+ recieve spam. 
> 
> Regards,
> Neil.

And so we should do nothing?

Re: WANTED: ISPs with DDoS defense solutions

[Jack Bates]

Randy Bush wrote:
anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.


it turns 1% of the technical problem into a massive social business
problem which, even if it was solvable (which it practically isn't),
would also be addressed by technical solutions where no spoofing is
involved.
Spoofed packets are harder to trace to the source than non-spoofed 
packets. Knowing where a malicious packet is very important to the 
process of trying to stop the malicious packet(s). Anyone without 
anti-spoof filtering has no interest in managing their network, keeping 
it secure, and assisting the Internet as a whole.

Without spoofing, one could take a list of 5,000 IP addresses involved 
in an attack and say, "These are either compromised or direct attacks," 
and issue reports to the correct people (with a few scripts). With 
spoofing, there is no reliable way of knowing if a host is compromised, 
the attacker, or if it's just another IP being spoofed. In such cases, 
on has to contact each IP owner and find out if spoof protection is 
enabled. If it is, then the party needs to look into the problem. If 
not, then it's just another waste of time.

-Jack

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Joel Baker]

On Mon, Aug 04, 2003 at 12:16:12PM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 04 Aug 2003 13:38:37 BST, [EMAIL PROTECTED]  said:
> 
> > The web of trusted email servers would use a new and improved mail 
> > transfer protocol (NIMTP) that would only be used to exchange email 
> > between trusted servers. Users could continue to use authenticated SMTP to 
> > initiate the sending of email, but nobody would accept any unauthenticated 
> > SMTP servers any more.

Hmmm. I fail, personally, to see why ESMTP couldn't handle it. Sure, it
would require a new extension, but what's what the E is for, isn't it?

Specifically, view it as a form of public-key certificate exchange, whether
you trust a central authority or a web of trust to establish that identity
(and, really, nothing says you couldn't do both). A signature from each hop
along the way (though normally this wouldn't be more than 2-3, since most
mailservers these days directly connect).

> And this would deploy how?  In particular, consider the following questions:
> 
> 1) What *immediate* benefits do you get if you are among the first to deploy?
> (For instance, note that you can't stop accepting "plain old SMTP" till
> everybody else deploys).

The very, very first to deploy? Very little, but also very little, if
any, cost - since nobody will invoke that extension, there's no crypto
verification overhead inbound or outbound. It costs a few bytes in your
EHLO block, I guess, and some code that will stay paged out once the
process has run for any length of time.

Almost the first to deploy, before wide adoption? Tie it into your other
spam filtering systems. Stuff from trusted sources (however that is
defined) can get tailored rules for each verified site (for most, that
probably means higher trust; for a few, lower).

> 2) Who bears the implementation cost when a site deploys, and who gets the
> benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want
> to do this?)

Like many game situations, all deployers benefit, in a curve related to the
number of deployers, and the cost hits each deployer. Making the overhead
cost very low (an extra config line the next time you upgrade sendmail, to
turn it on, and adding certificates for sites you actually care about, if
and when you care about them) would remove most of the pain. A marginal
cost to deploy, weighed against a benefit based on the risk of others
deploying, can still be an acceptable business risk.

> 3) What percentage of sites have to deploy before it makes a real difference,
> and what incremental benefit is there to deploying before that? (For any given
> scheme that doesn't fly unless 90% or more of sites do it, explain how you
> bootstrap it).

Two sites that speak to each other will potentially make a difference to
those two sites. Value as deployment increases is probably better than
linear, for most calculations of value return (I'm sure there are some
where it might not be; they don't have to deploy, if the cost is higher
than the value return, but that seems likely to be rare *if* it's done
properly).

> 4) Does the protocol still keep providing benefit if everybody deploys it?
> (This is a common problem with SpamAssassin-like content filters - if most
> sites filter phrase "xyz", spammers will learn to not use that phrase).

Yes. It provides more benefit the more sites deploy it, by building a
cohesive web of trusted servers within which one can believe, with some
reasonable expectation of being correct, that you know who is actually
talking to you - and make secondary decisions based on that, much as many
folks now do with RBLs.

> If you have a *serious* proposal that actually passes all 4 questions (in
> other words, it provides immediate benefit to early adopters, and still
> works when everybody does it), bring it on over to '[EMAIL PROTECTED]'.

The devil is, of course, in the details. The most crucial of them being
that it *must* be extremely easy to implement, likely to be implementable
in widespread software releases, and that the incremental overhead of use
must be small enough that the value provided is greater, in most cases.

In my opinion, at least, the value derived isn't from stopping spam;
spammers will still use throwaway accounts, folks will still try to
scam others, none of this will magically stop existing. The value is in
establishing a single, verifiable, consistant identity for any system with
which you might wish to talk, so that you can make decisions based on that
identity (or the lack thereof).

Much of this is based on my observations of the use and adopting of PGP and
SSL certificates. I don't sign all of my messages - most of them, yes, but
I occasionally don't do so if I expect the recipient might have problems
reading it, and if the recipient is valuble enough to make that choice.
Even though 90% of the mail coming to my inbox isn't PGP signed, it also
doesn't incur any extra cost; my client supports it automagically, and only
invokes 

Re: WANTED: ISPs with DDoS defense solutions

[Jared Mauch]

On Mon, Aug 04, 2003 at 05:28:07PM -0400, [EMAIL PROTECTED] wrote:
> 
> > I'm all for raising the bar on attackers and having end networks implement
> > proper source filtering, but even with that 1000 nt machines pinging 2
> > packet per second is still enough to destroy a T1 customer, and likely
> > with 1500 byte packets a T3 customer as well. You can't stop this without
> > addressing the host security problem...
> 
> Do you believe backbone networks should do nothing?

I'm not sure what you are saying here, backbones do do
something, the problem is that it's easy to fill up a T1.  *really* easy.

Just grab a few smurf amps and you can do it in a few seconds
if you can send spoofed traffic.

Or compromise a machine in a colo and type ping -f 

The backbones can't do much about this as if someone is within
their burstable bandwidth (or purchased), how are they to know that this
traffic is not legitimate.  There will always be "i've got bigger pipes
than you" issues such as this.

So, you need to have hosts (and routers) to be secured such
that they can't be compromised.  the *nix installations have been
moving towards this over time.  Note that RedHat no longer allows
inbound connections by default in rh9 on anything, they use iptables
to drop all this traffic.  Much different than the 3.0.3 days where
you got your INN server, mars-nwe, etc.. all installed so you had
a whole plethora of things that could be compromised as compared to
now.

the *BSD unices have also been securing themselves slowly over
time as well, bind and sendmail no longer run as root very long in their
default configurations (other than to bind to the ports), and there are
other limitations that are being added as well.

I won't speak for Washington State based companies and their
default security profiles and what (little) has been done to shift those
during the same timeframe..

I'm just hoping that people do change the mentality as follows:

You have to know how to turn the service on to open the ports.
This tends to mean that you know what you're doing in the first
place, or have done it on purpose and (might) have an idea of the
security implications of enabling such a service.

While this may not hold true, it does possibly shift some
of the liability onto the end-user.  You enabled it, you got rooted via it,
you should know to keep updated.

This also means that if you don't do anything, you by default
are not listening on ports 135-139,445, etc.. to get compromised,
winpopup spam, etc..

it would allow the enterprise people to also enable things as
necessary when they do their default template installs as well..

and everyone becomes happy.

- jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: WANTED: ISPs with DDoS defense solutions

[Randy Bush]

 Filtering the bogons does help, and everyone should perform anti-spoofing
 in the appropriate places.  It isn't, however, a silver bullet.
>>> it's necessary but not sufficient.
>> anti-spoofing is useful, but vastly insufficient, and hence not necessary
> anti-spoofing eliminates certain avenues of attack allowing one to focus
> on remaining avenues, and hence (as Vix stated) is necessary but not
> sufficient.

it turns 1% of the technical problem into a massive social business
problem which, even if it was solvable (which it practically isn't),
would also be addressed by technical solutions where no spoofing is
involved.

but it would provide a lot of fun and soapboxes for wannabe net
police and vigilantes.

randy

Re: WANTED: ISPs with DDoS defense solutions

[bdragon]

> >> Filtering the bogons does help, and everyone should perform anti-spoofing
> >> in the appropriate places.  It isn't, however, a silver bullet.
> > it's necessary but not sufficient.
> 
> anti-spoofing is useful, but vastly insufficient, and hence not necessary
> 
> randy

anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.

Re: WANTED: ISPs with DDoS defense solutions

[bdragon]

> I'm all for raising the bar on attackers and having end networks implement
> proper source filtering, but even with that 1000 nt machines pinging 2
> packet per second is still enough to destroy a T1 customer, and likely
> with 1500 byte packets a T3 customer as well. You can't stop this without
> addressing the host security problem...

Do you believe backbone networks should do nothing?

Re: Humidity ranges?

[Richard Parker]

For a datacenter with a single controlled area the ideal range for relative
humidity (RH) is in the neighborhood of 35% to 50%.

Here are some data points:

  1)  Static electricity is minimized when RH is at or above 35%.

  2)  RH below 25% can cause embrittlement of hygroscopic materials
  such as paper.

  3)  RH above 65% can cause mold growth and metal corrosion.

  4)  Humans are most comfortable when the RH is between 20% and 60%.

  5)  RH above 50% in cold weather can cause condensation inside of
  outer walls (or on equipment itself if the facility has an
  external door or window that opens directly into the controlled
  area).  

Sean Donelan wrote an informative post on a related subject a few year back:

  

-Richard

Re: Humidity ranges?

[Frank Louwers]

On Mon, Aug 04, 2003 at 01:02:46PM -0700, Steve Francis wrote:
> And reasonable thresholds that I can tolerate, and when I should 
> complain to the datacenter operators? (References I can point to would 
> be nice.)

depends what's in your SLA. If it states 40-65%, and you notice it's
over 68% or so, you SHOULD complain. Otherwise, you "agree" to the
higher %, if they can prove you know about the higher %. (IANAL)...

Of course, there's a difference between complaining, and demanding
refund. However, I think it's wise to complain...


Kind Regards,
Frank Louwers

-- 
Openminds bvbawww.openminds.be
Tweebruggenstraat 16  -  9000 Gent  -  Belgium

RE: Humidity ranges?

[N. Richard Solis]

 IIRC, too low a humidity level makes static electricity a problem.  Too high makes 
the cold air condense on your equipment.  60-65% sounds about right.


 
Todd Mitchell - lists wrote:
 
>
> | and when I should
> | complain to the datacenter operators? (References I can point to would
> | be nice.)
>
> When your equipment starts to rust ;)
>
> I don't have any technical references, but I think that anything over
> 65% is probably too much.  Most facilities I have equipment in do not
> exceed that mark.
>
> Todd
>
> --  
>
>
>

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Valdis . Kletnieks]

On Mon, 04 Aug 2003 19:41:35 BST, Richard D G Cox <[EMAIL PROTECTED]>  said:

> The immediate benefit (as sender) is that you reduce the (now ever-increasing)
> risk of your mail being rejected by filtration processes and will be trusted
> on arrival; the benefit for the recipient is of course less junk!

Erm. No.  You only get benefit as *other* sites deploy. If they haven't bought
in, they won't contact your new service. Or to use a totally different example
- if you've deployed IPv6, you won't actually get connections from other sites until
THEY put up IPv6 too.

Your users receive less junk only once a significant number of other sites deploy.

> However you CAN stop accepting "plain old SMTP" right away, because you can
> delegate that to a filtration service that hosts your old-style MX, applies
> ever-increasingly stringent filtration rules, and then forwards to you using
> the new protocol. Several such filtrations services may well appear when the
> time is right.

And this is an improvement over just applying the filtration rules *how*? ;)

"Since SpamAssassin isn't good enough to solve the problem, I'll run it over THERE
instead, and then forward 99.9% of my mail to here over new protocol XYZ".
 
> > 2) Who bears the implementation cost when a site deploys, and who gets
> >the benefit? (If it costs *me* to deploy, but *you* get the benefit,
> >why do I want to do this?)
> 
> Both parties get benefits which seriously outweigh the costs!

Enumerate.  Remember *not* to count benefits that aren't a result of your
protocol change...

> > 3) What percentage of sites have to deploy before it makes a real
> > difference, and what incremental benefit is there to deploying before tha=
> t?
> 
> To some extent the concept is already here, and deployed, whether using
> in-house filters or remote-MX, to subject the unauthenticated mail - which
> of course is currently ALL the mail - to appropriate filtering.

Right.. so you can't count "filtering" as a benefit (see above).  So what benefit
do you get for doing it *before* it reaches critical mass?

> That goes for any precautions taken - not just content filters.  That is WHY
> the contractual relationships are absolutely essential for any new scheme.
> And there, too, lies the bulk of the work needed - the technical issues do
> not place any great demands on the networking community.

Gaak.  There was a *reason* the X.400 concept of ADMD and PRMD died
an ugly death - it doesn't scale well at all.  "Contractual relationships" is just
a buzzword meaning "whitelisting after the lawyers got hold of it". :)

ObNANOG:  If this goes through, it will be considered a revenue source by
many providers.  See "peering versus buying transit" for details. ;)

> > If you have a *serious* proposal that actually passes all 4 questions
> > (in other words, it provides immediate benefit to early adopters, and
> > still works when everybody does it), bring it on over to '[EMAIL PROTECTED]'.
> 
> Heh.  The noise-to-signal level *there* is far worse than in NANOG - by at
> least 12dB last time I looked ;-)

Would improve vastly if asrg wasn't spending so much time thrashing yet
another non-bootstrappable proposal to death :)

And to the other responder who's name I've lost- yes, there's no good technical
solution to spam. That's why I advocate collecting $500 from each ISP to hire
some muscle from a suitable ethnic organized crime organization (I'm told
competition is driving the costs down ;) to "explain our position and make some
examples".  This would quickly change the percieved economics of spamming -
that $4K/week suddenly looks a *lot* less inviting when you know the last guy
who tried it got a visit from 3 guys with baseball bats... ;)



pgp0.pgp
Description: PGP signature

RE: Humidity ranges?

[Todd Mitchell - lists]

| and when I should
| complain to the datacenter operators? (References I can point to would
| be nice.)

When your equipment starts to rust ;)

I don't have any technical references, but I think that anything over
65% is probably too much.  Most facilities I have equipment in do not
exceed that mark.

Todd

--

Humidity ranges?

[Steve Francis]

We have sensors in our datacenters that report, among other things, 
humidity.
One data center is exceeding the predefined humidity alerts of the 
devices, but given that cisco says the operating humidty of routers is 
10% to 85%, I dont know if humidity of, say,  65% is anything to worry 
about.
Anyone know if increased humidity correlates with decreased MTBF?
And reasonable thresholds that I can tolerate, and when I should 
complain to the datacenter operators? (References I can point to would 
be nice.)

Thanks

Inconsistant origins

[Joe Provo]

On Mon, Aug 04, 2003 at 08:35:14PM +0200, Mikael Abrahamsson wrote:
> On Mon, 4 Aug 2003, Mike Donahue wrote:
> > My company owns a class C, and we're switching ISPs.  The "new" 
> > provider is telling us that they can start announcing, without us 
> > having to tell the old provider to stop announcing.  I.e., a 2-3 
> > day period where both are announcing our class C.

Inconsistant origins are bad. Which path is supposed to be believed? 
Which path is supposed to be selected? From what point of view? None 
of these are defined conditions; non-determinism is not good for
performance. Expect some things to work, some things to be strange, 
and some to be lousy. 

Your best bet is to minimize the overlap period.

Joe

-- 
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Neil J. McRae]

I would have though people would have learned by now that 
there is no technical solution to spam. You can go ahead
with all these wonderfully expensive 
authentication/filtration/insertantispambuzzword systems until 
the cows come home and you will +_still_+ recieve spam. 

Regards,
Neil.

RE: AS announcement question (easy)

[Pete Templin]

Is it a class C, or a /24?  

Regardless, longest match wins.  If old provider is announcing your space as part of a 
larger announcement, you'll be a bad netizen for a few days because you're violating 
the RFCs concerning inconsistent AS, but your traffic will swing almost entirely over 
to new provider, and rather quickly.  Traffic originating in old provider's network 
will likely still come in on your old link.  (I've done this for three new customers 
in the past month.)  If your old provider is specifically announcing your space as a 
/24, standard BGP path selection processes will take place all over the 'Net, and YMMV 
on the traffic balance.  On or before disconnecting the link to old provider (if they 
are specifically announcing your /24), be sure to have them stop announcing that /24.

Pete Templin
Senior Staff Engineer
TexLink Communications
(210) 892-4183
[EMAIL PROTECTED]


-Original Message-
From: Mike Donahue [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 1:22 PM
To: '[EMAIL PROTECTED]'
Subject: AS announcement question (easy)


Hi, sorry for this low-level question, but at least I'm not posting in html.
:)

My company owns a class C, and we're switching ISPs.  The "new" provider is
telling us that they can start announcing, without us having to tell the old
provider to stop announcing.  I.e., a 2-3 day period where both are
announcing our class C.

This conflicts with my extremely (admittedly)limited knowledge.  Can someone
let me know if this is OK/not OK?

Thanks in advance,

Mike

Michael Donahue
WATG
(949) 574-8500 x261

Re: WANTED: ISPs with DDoS defense solutions

[Scott Francis]

On Thu, Jul 31, 2003 at 09:09:34PM +0300, [EMAIL PROTECTED] said:
[snip]

> > What we need is a new programming paradigm, capable of actually producing
> > secure (and, yes, reliable) software.  C and its progeny (and "program
> > now, test never" lifestyle) must go.  I'm afraid it'll take laws which
> > would actually make software makers to pay for bugs and security
> > vulnerabilities in shipped code to make such paradigm shift a reality.
> >
> Blaming the tools for the mistakes programmers make is like saying "guns
> kill people" when the truth is that people kill people with guns.

Pete is right. There is no tool sufficiently safe as to prevent abuse, and
yet still be useful. Or more succinctly, "Nothing is foolproof to a
sufficiently talented fool."
-- 
Scott Francis || darkuncle (at) darkuncle (dot) net
  illum oportet crescere me autem minui


pgp0.pgp
Description: PGP signature

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Richard D G Cox]

Valdis Kletnieks <[EMAIL PROTECTED]> wrote:
> 1) What *immediate* benefits do you get if you are among the first to
>  deploy? (For instance, note that you can't stop accepting "plain old
>  SMTP" till everybody else deploys).

The immediate benefit (as sender) is that you reduce the (now ever-increasing)
risk of your mail being rejected by filtration processes and will be trusted
on arrival; the benefit for the recipient is of course less junk!

However you CAN stop accepting "plain old SMTP" right away, because you can
delegate that to a filtration service that hosts your old-style MX, applies
ever-increasingly stringent filtration rules, and then forwards to you using
the new protocol. Several such filtrations services may well appear when the
time is right.

> 2) Who bears the implementation cost when a site deploys, and who gets
>the benefit? (If it costs *me* to deploy, but *you* get the benefit,
>why do I want to do this?)

Both parties get benefits which seriously outweigh the costs!

> 3) What percentage of sites have to deploy before it makes a real
> difference, and what incremental benefit is there to deploying before that?

To some extent the concept is already here, and deployed, whether using
in-house filters or remote-MX, to subject the unauthenticated mail - which
of course is currently ALL the mail - to appropriate filtering.

> (For any given scheme that doesn't fly unless 90% or more of sites do it,
> explain how you bootstrap it).

That is a very valid point that most people don't address.  I define any
new scheme as unworkable unless someone can describe the present, albeit
unsatisfactory, arrangements that it offers to replace as a "special case"
of the new scheme for which there is clearly-defined correct handling.

> 4) Does the protocol still keep providing benefit if everybody deploys it?

That depends entirely on the contactual relationships that may exist between
mail-exchanging sites.  Just implementing an authenticating protocol on its
own will NOT help.  There will be a prima-facie need for a selection of
"trust-authorities" who specify what is acceptable for their trusted-senders
to send.  Recipients then get to choose which criteria are closest to their
requirements (including whitelisting if needed on a per-site basis).
 
> (This is a common problem with SpamAssassin-like content filters - if most
> sites filter phrase "xyz", spammers will learn to not use that phrase).

That goes for any precautions taken - not just content filters.  That is WHY
the contractual relationships are absolutely essential for any new scheme.
And there, too, lies the bulk of the work needed - the technical issues do
not place any great demands on the networking community.

> If you have a *serious* proposal that actually passes all 4 questions
> (in other words, it provides immediate benefit to early adopters, and
> still works when everybody does it), bring it on over to '[EMAIL PROTECTED]'.

Heh.  The noise-to-signal level *there* is far worse than in NANOG - by at
least 12dB last time I looked ;-)

--
Richard Cox
RC1500-RIPE

Inconsistent AS, was Re: AS announcement question (easy)

[Rob Thomas]

Hi, NANOGers.

] See "show ip bgp inconsistant-as" on cisco. YMMV.

On that theme, please also see:

   
   

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: North America not interested in IP V6

[Scott Francis]

On Fri, Aug 01, 2003 at 07:52:09PM -0400, [EMAIL PROTECTED] said:
> 
> Is there a way to block html mail at the edge using a proxy ro something?

anything's possible given sufficient resources, but this is not a workable
solution - this needs to be addressed at the client level. Anything else will
only frustrate end-users or bog down the network or both.
-- 
Scott Francis || darkuncle (at) darkuncle (dot) net
  illum oportet crescere me autem minui


pgp0.pgp
Description: PGP signature

Re: AS announcement question (easy)

[alex]

> Hi, sorry for this low-level question, but at least I'm not posting in html.
> :)
> 
> My company owns a class C, and we're switching ISPs.  The "new" provider is
> telling us that they can start announcing, without us having to tell the old
> provider to stop announcing.  I.e., a 2-3 day period where both are
> announcing our class C.
> 
> This conflicts with my extremely (admittedly)limited knowledge.  Can someone
> let me know if this is OK/not OK?

If you are going to have your link up to both providers during that time, it
would not be a problem. However, if your /24 is nailed into the tables of
your previous provider, and your link to that provider is down, then the old
provider will create a blackhole for /24 for anyone who prefers the path
presented by your old provider.

In general, one really *should* coordinate switching between providers if
ones' announcement is originated by the provider.

Alex

> 
> Thanks in advance,
> 
> Mike
> 
> Michael Donahue
> WATG
> (949) 574-8500 x261
> 
> 

Re: AS announcement question (easy)

[Mikael Abrahamsson]

On Mon, 4 Aug 2003, Mike Donahue wrote:

> My company owns a class C, and we're switching ISPs.  The "new" provider is
> telling us that they can start announcing, without us having to tell the old
> provider to stop announcing.  I.e., a 2-3 day period where both are
> announcing our class C.
> 
> This conflicts with my extremely (admittedly)limited knowledge.  Can someone
> let me know if this is OK/not OK?

Originating the same prefix from two different ASes violates the RFC (or
whatever bible you might pray to), but works most of the time. 

See "show ip bgp inconsistant-as" on cisco. YMMV.

-- 
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: AS announcement question (easy)

[H. Michael Smith, Jr.]

If the old provider is advertising the prefix based on your
advertisement to them (you're running BGP), then their advertisement
should cease shortly after your link to them goes down.  Likewise, the
new provider would only propagate the advertisement after you advertise
it to them.

Michael

H. Michael Smith, Jr.
Network Services and Security Manager
Clark Atlanta University


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mike Donahue
Sent: Monday, August 04, 2003 2:22 PM
To: '[EMAIL PROTECTED]'
Subject: AS announcement question (easy)


Hi, sorry for this low-level question, but at least I'm not posting in
html.
:)

My company owns a class C, and we're switching ISPs.  The "new" provider
is
telling us that they can start announcing, without us having to tell the
old
provider to stop announcing.  I.e., a 2-3 day period where both are
announcing our class C.

This conflicts with my extremely (admittedly)limited knowledge.  Can
someone
let me know if this is OK/not OK?

Thanks in advance,

Mike

Michael Donahue
WATG
(949) 574-8500 x261

AS announcement question (easy)

[Mike Donahue]

Hi, sorry for this low-level question, but at least I'm not posting in html.
:)

My company owns a class C, and we're switching ISPs.  The "new" provider is
telling us that they can start announcing, without us having to tell the old
provider to stop announcing.  I.e., a 2-3 day period where both are
announcing our class C.

This conflicts with my extremely (admittedly)limited knowledge.  Can someone
let me know if this is OK/not OK?

Thanks in advance,

Mike

Michael Donahue
WATG
(949) 574-8500 x261

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Jason Robertson]

Also the fact that the transition time would require many companies to 
run 2 or more protocols.  And simply put the majority of SMTP isn't 
bad, if fully implemented as a single standard and implemented by 
vendors and developers.

But the idea isn't bad, but may have massive cost additions, if you are 
going to authenticate servers, we would basically be better off to run 
a FIDONET netmail configuration, where you must register to a 
controlling party, but then that may mean a monthly charge.

Though I do have my own proposal sitting ontop of SMTP, and used 
initially as something to determine the level of filtering to do, it 
would reduce requirements on dns queries to various rbl's.

It will also validate headers and each host along the way.

Another thing that I am putting in the ID.. is standard error message 
formats, it would make life easier for maillist owners, there is one 
mail server that sends back only the account name of an invalid 
mailbox, without a domain or email address to help even figure which 
message failed.

Jason

On 4 Aug 2003 at 12:16, [EMAIL PROTECTED] wrote:

> On Mon, 04 Aug 2003 13:38:37 BST, [EMAIL PROTECTED]  said:
> 
> > The web of trusted email servers would use a new and improved mail 
> > transfer protocol (NIMTP) that would only be used to exchange email 
> > between trusted servers. Users could continue to use authenticated SMTP to 
> > initiate the sending of email, but nobody would accept any unauthenticated 
> > SMTP servers any more.
> 
> And this would deploy how?  In particular, consider the following questions:
> 
> 1) What *immediate* benefits do you get if you are among the first to deploy?
> (For instance, note that you can't stop accepting "plain old SMTP" till
> everybody else deploys).
> 
> 2) Who bears the implementation cost when a site deploys, and who gets the
> benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want
> to do this?)
> 
> 3) What percentage of sites have to deploy before it makes a real difference,
> and what incremental benefit is there to deploying before that? (For any given
> scheme that doesn't fly unless 90% or more of sites do it, explain how you
> bootstrap it).
> 
> 4) Does the protocol still keep providing benefit if everybody deploys it?
> (This is a common problem with SpamAssassin-like content filters - if most
> sites filter phrase "xyz", spammers will learn to not use that phrase).
> 
> If you have a *serious* proposal that actually passes all 4 questions (in
> other words, it provides immediate benefit to early adopters, and still
> works when everybody does it), bring it on over to '[EMAIL PROTECTED]'.
> 
> 
> 

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Valdis . Kletnieks]

On Mon, 04 Aug 2003 13:38:37 BST, [EMAIL PROTECTED]  said:

> The web of trusted email servers would use a new and improved mail 
> transfer protocol (NIMTP) that would only be used to exchange email 
> between trusted servers. Users could continue to use authenticated SMTP to 
> initiate the sending of email, but nobody would accept any unauthenticated 
> SMTP servers any more.

And this would deploy how?  In particular, consider the following questions:

1) What *immediate* benefits do you get if you are among the first to deploy?
(For instance, note that you can't stop accepting "plain old SMTP" till
everybody else deploys).

2) Who bears the implementation cost when a site deploys, and who gets the
benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want
to do this?)

3) What percentage of sites have to deploy before it makes a real difference,
and what incremental benefit is there to deploying before that? (For any given
scheme that doesn't fly unless 90% or more of sites do it, explain how you
bootstrap it).

4) Does the protocol still keep providing benefit if everybody deploys it?
(This is a common problem with SpamAssassin-like content filters - if most
sites filter phrase "xyz", spammers will learn to not use that phrase).

If you have a *serious* proposal that actually passes all 4 questions (in
other words, it provides immediate benefit to early adopters, and still
works when everybody does it), bring it on over to '[EMAIL PROTECTED]'.




pgp0.pgp
Description: PGP signature

RE: [operations] FW: abuse case management

[Damian Gerow]

On Mon, 4 Aug 2003, William Devine, II wrote:
> I used RT a looong time ago around 1998 & 1999 and liked it, but OTRS,
> compared to THEN features is superior.  I haven't tried RT yet, although I
> did start installing it and I know I gave up on RT once when trying to
> install it but got OTRS up and running rather easily, so I can't say about
> their new things.   
> I do know that there is a feature article this month in Linux journal, Linux
> review or one of the Linux related mags that states that OTRS is used by one
> national British ISP that pumps 20,000 tickets per DAY through it, and one
> business that has around 2,000 CSR's using OTRS for customer support
> services, both using MySQL as the database backend.   I thought that was a
> pretty good testament as well.

We have been using RT for some time now, and it's incredibly easy to get up
and running (especially with a ports system).  It's not even close to
processing 20k tickets/day, but it definitely handles what we give it.

RT has its quirks, but Jesse Vincent is a good guy, and it's mindbogglingly
easy to customize it.  There's more testemonials in the NANOG archives I
believe.

And getting back to the original post...


Mikael Abrahamsson asked:
> Is there an abuse case management system as freeware somewhere, something
> like all the ticket/case handling packages out there, but more
> specifically aimed at abuse/complaint handling. I googled some but couldnt
> find any.

I haven't checked it out yet, but Jesse's written an interface to RT
specifically for Abuse desks - it's called RTIR.  Look through
http://www.bestpractical.com/ and http://www.fsck.com/pub/ for mote details.

  - Damian

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[David Lesher]

Speaking on Deep Background, the Press Secretary whispered:
 
> Having an abuse@ email address may be customary Internet behavior but it 
> is no longer reasonable. The fact is that SMTP email has outlived its 
> usefulness and needs to be replaced with something that provides a chain 
> of authentication that certifies the sender's identity. 

Will eBay do business with me if THEY have to type in a 1" square
on MY webform?



-- 
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

RE: [operations] FW: abuse case management

[William Devine, II]

I used RT a looong time ago around 1998 & 1999 and liked it, but OTRS,
compared to THEN features is superior.  I haven't tried RT yet, although I
did start installing it and I know I gave up on RT once when trying to
install it but got OTRS up and running rather easily, so I can't say about
their new things.   
I do know that there is a feature article this month in Linux journal, Linux
review or one of the Linux related mags that states that OTRS is used by one
national British ISP that pumps 20,000 tickets per DAY through it, and one
business that has around 2,000 CSR's using OTRS for customer support
services, both using MySQL as the database backend.   I thought that was a
pretty good testament as well.

william

-Original Message-
From: ODHIAMBO Washington [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 04, 2003 8:32 AM
To: [EMAIL PROTECTED]
Cc: William C. Devine II; [EMAIL PROTECTED]
Subject: Re: [operations] FW: abuse case management


This is for William Devine and the nanog staff: I have a question.
Have any of you had the chance to try out RT (Request Tracker) available
at http://www.bestpractical.com/ and compared it with OTRS??? I would
be interested in the comparison of features, but if I have to install
OTRS to compare, then I will spare some time to try it out in due course.

-Wash

* Joseph Mucheru <[EMAIL PROTECTED]> [20030803 09:49]: wrote:
> 
> 
> -- Forwarded Message
> From: "William Devine, II" <[EMAIL PROTECTED]>
> Date: Fri, 1 Aug 2003 06:06:51 -0500
> To: <[EMAIL PROTECTED]>
> Subject: RE: abuse case management
> 
> 
> I started using OTRS (Open Ticket Request System) a month or so ago and
LOVE
> IT.  You can setup pre-canned response templates and have multiple users
> login and maintain various queues.  It's open source and works VERY well.
> 
> http://www.otrs.org/
> 
> william
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Mikael Abrahamsson
> Sent: Friday, August 01, 2003 4:08 AM
> To: [EMAIL PROTECTED]
> Subject: abuse case management
> 
> 
> Is there an abuse case management system as freeware somewhere, something
> like all the ticket/case handling packages out there, but more
> specifically aimed at abuse/complaint handling. I googled some but couldnt
> find any.
> 
> My idea is that it should provide functions to do the following flow:
> 
> Abuse complaint comes in via email, is scanned if it's in a certain
> format, if it is, put it directly into the case handling system.
> 
> If not, This email is presented to the handler on a web page. The handler
> looks at the email and decides whether the email has enough information in
> it to be a complete abuse complaint.
> 
> If NO, press button to send back a form to the one who complained stating
> what information is needed and that they can either fill in the email form
> and return the email, or go to a web page and fill it in (the link should
> go to their original complaint so they can add information).
> 
> If YES, the handler puts complaint IP adress, time and type of complaint
> in some web fields and then presses another button to put the complaint
> (now categorized) into the case handling system.
> 
> This, coupled to a customer IP database, will enable daily reporting on
> top customers who get complained about, bundling of complaints per
> customer etc, plus it makes the process of cases without enough
> information take 5-10 seconds to handle.
> 
> This is a variation on the telia web way that was complained about a month
> back or so, in that it enables the same categorization by a handler in an
> efficiant (?) way.
> 
> It was mentioned in the earlier discussion that we should have a
> standardized way of reporting abuse via email. Was anything ever done
> about this, or should we try to just make a de facto form that might
> spread if more ISPs adopt it? Do the spamcop etc people have any
> suggestions on how to handle the huge amount of complaints they generate?
> 
> Any suggestions welcome.
> 
> -- 
> Mikael Abrahamssonemail: [EMAIL PROTECTED]
> 
> 
> -- End of Forwarded Message
> 
> -- 
>  discussion forum for Wananchi Online Operations Dept.
>   [EMAIL PROTECTED]



Best regards,
Odhiambo Washington
Wananchi Online Ltd.


___W_A_N_A_N_C_H_I__O_N_L_I_N_E__L_T_D___The People's Choice__
Wananchi Head Office|*| Tel: +254 2 313 985-9
1st Flr Loita, Loita St.|*| Fax: +254 2 313 922
10286-GPO, NAIROBI, KE  |*| e-mail: 
--
++

Micros~1 :
 For when quality, reliability
  and security just aren't
   that important!
 

Re: Complaint of the week: Ebay abuse mail (slightly OT)

[Michael . Dillon]

>we all knew that profitable large network owners would change the 
landscape
>compared to merely ebitda-positive large network owners, and here's an
>example of how "big company" cost management practices can go up against
>"reasonable and customary internet behaviour" and pretty much ignore it.

Having an abuse@ email address may be customary Internet behavior but it 
is no longer reasonable. The fact is that SMTP email has outlived its 
usefulness and needs to be replaced with something that provides a chain 
of authentication that certifies the sender's identity. Once email senders 
are no longer able to falsify their identity, then it will again be 
economically feasible for companies to accept abuse@ email from anyone.

Instead of working to prevent email relaying, we should be working to 
encourage it along with certification of the sender's identity. If we had 
a web of ISP mail servers that trust each other to certify the sender's 
identity, then people would be happy to accept any and all email relayed 
through that web.

The web of trusted email servers would use a new and improved mail 
transfer protocol (NIMTP) that would only be used to exchange email 
between trusted servers. Users could continue to use authenticated SMTP to 
initiate the sending of email, but nobody would accept any unauthenticated 
SMTP servers any more.

--Michael Dillon