Re: OT - 3 Free Gmail invites

[Joe Shen]

Gmail seems to be in Beta stage. I got a Gmail account
months ago, but I do not use it by now.
The reason is it does not solve two bugs I met. 
The first is, after logining into gmail it will prompt
with "Ooops, the system was unable to perform your
operation. Please try again in a few seconds" if I
click "Compose Mail". Sometime this message comes up
after I FINALLY succeed with "Compose MAIL" and click
"Send".

Another thing I met is, when trying to log in. After
typing in username/password, it shows "Gmail is not
available by now", and I have to reload one or two
times to log in. 

This is really contrast to what Yahoo! could provide.

Joe
  


 --- Brett <[EMAIL PROTECTED]> wrote:  
> 
> WOW!  Overwhelming response.  Haven't sent them all
> out yet, but all
> accounted for.
> 
> Brett
> 
> On Wed, 18 Aug 2004 13:51:43 -0700, Brett
> <[EMAIL PROTECTED]> wrote:
> > I've got a few to give out as well.  Email me
> off-list and if I have
> > any left, I'll send an invite.
> > 
> > Brett
> > 
> > On Wed, 18 Aug 2004 16:43:30 -0400, Joshua Brady
> <[EMAIL PROTECTED]> wrote:
> > >
> > > All gone
> > >
> >
>  

__
Do You Yahoo!?
Download the latest ringtones, games, and more!
http://sg.mobile.yahoo.com

RE: Specialty Technical Publishers

[Michel Py]

>> Michel Py wrote:
>> File a complaint with the BBB of Vancouver, BC. They are known
>> to the BBB. Then, let their collection goons waste their time
>> and their money, and tell them that if they want to see it back
>> they have to send you a prepaid box.

> Mike Lewinski wrote:
> Ah, excellent pointer! I see the Vancouver BBB lists this
> report on their website also indicating a pattern of abuse:
> http://166.70.33.197/~van/commonreport.html?bid=105759

Yeah, that's the kind of customer that has a valid address on each side
of the US/Canada border, and I'm happy to have their Internet service
provided by a competitor. Sooner or later, someone is going to get
pissed and let some steam out with one of these $65 DDOS that Alexei
mentioned sometime ago.

Michel.

Re: OT - 3 Free Gmail invites

[Deepak Jain]

You know, I'm having trouble finding people that *don't* have gmail.com 
accounts already. :P

-Jonathan "G-mail-less" Nichols
If we are all network operators, exactly what is the benefit of having a 
1GB mailbox operated by another network?

Deepak "150GB and growing" Jain

Re: OT - 3 Free Gmail invites

[Jonathan Nichols]

Joshua Brady wrote:
I've got 2 Gmail invites up for grabs for the first 2 to email me offlist.
You know, I'm having trouble finding people that *don't* have gmail.com 
accounts already. :P

-Jonathan "G-mail-less" Nichols

RE: Blocked port 25?

[David Schwartz]

> In the last couple of days, I have received complaints from customers
> not able to receive email from certain sites.

If I understand you correctly, you are saying that these sites are not able
to send mail to you. Assuming that they are diverse sites that don't have
significant similarities, this suggests that the problem is on your end.

> From these sites, I
> can't connect to our mail server, on other sites, I can.

I don't understand what this is supposed to mean. It's their mail servers
that are supposed to try to connect to your mail server.

> We have tried
> sending email, and we have also tried telnet on port 25 to the server.
> I can't seem to find a correlation.  There is no firewall on our
> network.  We have an access list to filter port 25, but this server is
> allowed.  Our mail server is also our DNS server.  From the sites that
> I can't connect to our server on port 25, I can query the DNS server
> using nslookup and get a response.

This doesn't tell you anything about why their mailservers might not be
able to reach your mailserver.

> I tried tcptraceroute from one of the sites where I have a unix
> account, but it is behind a firewall, and it dies after the first hop.
> I'm stumped.  Any suggestions.

You really haven't given a clear description of the problem. When you say
customers can't receive email from certain sites, I'm assuming this means
people at those sites send email to your customers and the email does not
appear in your customers inboxes. From this, I would conclude that their
mailservers are not able to (or willing to) send the email to your
mailserver.

When you say you can't connect to your server on port 25, where exactly are
you trying from? Did you try emailing (or calling) the administrators of
those sites? If you use SPF, are your records valid? Do the senders get any
bounces?

Your statement of the problem is lack of specifics. We can't check your SPF
records. We can't check if those domains have a common provider. So all we
can do is tell you to troubleshoot.

DS

Blocked port 25?

[Byron L . Hicks]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In the last couple of days, I have received complaints from customers 
not able to receive email from certain sites.   From these sites, I 
can't connect to our mail server, on other sites, I can.  We have tried 
sending email, and we have also tried telnet on port 25 to the server.  
I can't seem to find a correlation.  There is no firewall on our 
network.  We have an access list to filter port 25, but this server is 
allowed.  Our mail server is also our DNS server.  From the sites that 
I can't connect to our server on port 25, I can query the DNS server 
using nslookup and get a response.

I tried tcptraceroute from one of the sites where I have a unix 
account, but it is behind a firewall, and it dies after the first hop.  
I'm stumped.  Any suggestions.

Byron L. Hicks
Network Engineer
NMSU ICT
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBJCBkROB/wlNWTDYRAgkOAJ9gqyg1RyQTpeNiTKvPQgGXig2KSACeOhjw
QFMw3oV620Y+/qCKRdvZKLc=
=ZmFh
-END PGP SIGNATURE-

Re: Specialty Technical Publishers

[Mike Lewinski]

Michel Py wrote:
File a complaint with the BBB of Vancouver, BC. They are known to the
BBB. Then, let their collection goons waste their time and their money,
and tell them that if they want to see it back they have to send you a
prepaid box.
Ah, excellent pointer! I see the Vancouver BBB lists this report on 
their website also indicating a pattern of abuse:

http://166.70.33.197/~van/commonreport.html?bid=105759
Better Business Bureau of Mainland B.C
BBB Reliability Report
Specialty Technical Publishers
10 1225 E Keith Rd
North Vancouver, BC V7J 1J3
General Information
Original Business Start Date:   December 1986
Principal:  Julie Farrell, Cust Services Mgr
Phone Number:   (604) 983-3434
Fax Number: (604) 983-3445
Membership Status:  No
Website Address:www.stpub.com
Customer Experience
Based on BBB files, this company has an unsatisfactory record with the 
Bureau due a pattern of complaints. Although the company resolves the 
complaints, it has failed to correct the underlying reason for the 
complaints.

Additional Information
Additional Doing-Business-As Names:

S T P Specialty Technical Publishers

S T P Specialty Technical Publishers
Additional TOB Classifications:
PUBLISHERS-DIRECTORY & GUIDE
Educational/General Comments
Unsolicited Invoices
TIPS FOR CONSUMERS - UNSOLICITED INVOICES:
For your information the BBB advises that it has received numerous 
complaints from businesses & organizations alleging they have received 
"invoices" for goods or services which they had not ordered, or "second 
notices" requesting payment when no "first notice" had been received. 
Sometimes, "final notices" have been received, threatening that the 
account would be turned over to a credit department and that such action 
could affect the credit rating of the organization and make it liable 
for collection and legal costs.

What you have received RESEMBLES an invoice. It may be, in fact, a form 
of advertising. You are not required to pay anything unless you wish to 
participate in the offer. In some cases the goods or services offered 
may be of lesser quality than the quality expected for the price. In 
many cases these look alike invoices are paid by unwary accounts payable 
personnel. Be sure to educate your staff to recognize solicitations in 
the form of look alike invoices. Also, be sure your payables system has 
at least two people to authorize any payments so they can check each other.

BBB Membership
This company is not a member of the Better Business Bureau.
Report as of 08/18/2004
Copyright© 2004 Better Business Bureau of Mainland B.C.
As a matter of policy, the Better Business Bureau does not endorse any 
product, service or company. BBB reports generally cover a three-year 
reporting period, and are provided solely to assist you in exercising 
your own best judgment. Information contained herein is believed 
reliable but not guaranteed as to accuracy. Reports are subject to 
change at any time.

The Better Business Bureau reports on members and non-members. 
Membership in the BBB is voluntary, and members must meet and maintain 
BBB standards. If a company is a member of this BBB, it is stated in 
this report.

RE: Specialty Technical Publishers

[Michel Py]

> Mike Lewinski wrote:
> Has anyone else has run into these scumbags? Sometime last
> winter I received a call along the lines of "We'd like to
> send you some materials to review". Well, they sent some
> "Internet Law encyclopedia" along with an invoice for ~$700.
> Of course, there was no cost mentioned in the sales call-
> for all I knew they were going to send me a brochure about
> their product. I can say with 100% certainty that I would
> never have authorized them to send me something like this
> had they mentioned the cost without much further discussion
> as to what I was receiving. This is just a general heads-up
> to a sleazy business practice for a sleazy company that is
> now attempting to extort money.

File a complaint with the BBB of Vancouver, BC. They are known to the
BBB. Then, let their collection goons waste their time and their money,
and tell them that if they want to see it back they have to send you a
prepaid box.

Michel.

Re: Specialty Technical Publishers

[Mike Lewinski]

Owen DeLong wrote:
No... It is not a good idea to /dev/null it.  If you /dev/null it, the
doctrine of Acquiescence by Estoppel works in their favor (essentially 
latin
legalise for "Silence is Consent").  Instead, you should write on the 
invoice
that you never agreed to purchase the items and send it back to them 
certified
mail.  Make a copy of the invoice with your annotation and keep it for your
records.
Thanks for the advice. I'm getting an opinion as to whether it is too 
late to follow this course, given that what led to my little outburst 
resulted from a call from their collections agency (I had actually asked 
to have it shipped back when it first arrived but the office manager had 
other more pressing things to do so it's been gathering dust, unopened 
except to look at the invoice). If we do send it back, it's going to be 
accompanied by an invoice for our shipping costs and time.

In any event, after doing some googling and finding other victims of 
this company, I've decided to register 
SpecialtyTechnicalPublishersSucks.com in order to publicly document 
their abuses. Sooner or later someone will have the time and resources 
to fight them all the way- perhaps I can lend some ammo.

So, this is an invitation to anyone who's had an experience with STP to 
submit it to me directly- I'll be happy to anonymize if requested when I 
publish it.

TIA,
Mike

Re: Specialty Technical Publishers

[Owen DeLong]

No... It is not a good idea to /dev/null it.  If you /dev/null it, the
doctrine of Acquiescence by Estoppel works in their favor (essentially latin
legalise for "Silence is Consent").  Instead, you should write on the 
invoice
that you never agreed to purchase the items and send it back to them 
certified
mail.  Make a copy of the invoice with your annotation and keep it for your
records.

At that point, they are pretty much stuck.
IANAL, but, this is what I've been told by lawyers.
Owen
--On Wednesday, August 18, 2004 7:38 PM -0400 Mark Barker <[EMAIL PROTECTED]> 
wrote:

Invoicing for unsolicited materials is commonly referred to as "mail
fraud" hereabouts.
The courts have consistently upheld the notion that such materials can be
considered gifts.
IANAL but I would advise /dev/nulling all further correspondence from
these losers.
-- MAB
On Aug 18, 2004, at 18:36, Mike Lewinski wrote:
Has anyone else has run into these scumbags? Sometime last winter I
received a call along the lines of "We'd like to send you some
materials to review". Well, they sent some "Internet Law encyclopedia"
along with an invoice for ~$700. Of course, there was no cost
mentioned in the sales call- for all I knew they were going to send me
a brochure about their product. I can say with 100% certainty that I
would never have authorized them to send me something like this had
they mentioned the cost without much further discussion as to what I
was receiving.
This is just a general heads-up to a sleazy business practice for a
sleazy company that is now attempting to extort money.


--
If it wasn't crypto-signed, it probably didn't come from me.


pgpN0t9PeBxte.pgp
Description: PGP signature

Re: Specialty Technical Publishers

[Mark Barker]

Invoicing for unsolicited materials is commonly referred to as "mail 
fraud" hereabouts.
The courts have consistently upheld the notion that such materials can 
be considered gifts.
IANAL but I would advise /dev/nulling all further correspondence from 
these losers.

-- MAB
On Aug 18, 2004, at 18:36, Mike Lewinski wrote:
Has anyone else has run into these scumbags? Sometime last winter I 
received a call along the lines of "We'd like to send you some 
materials to review". Well, they sent some "Internet Law encyclopedia" 
along with an invoice for ~$700. Of course, there was no cost 
mentioned in the sales call- for all I knew they were going to send me 
a brochure about their product. I can say with 100% certainty that I 
would never have authorized them to send me something like this had 
they mentioned the cost without much further discussion as to what I 
was receiving.

This is just a general heads-up to a sleazy business practice for a 
sleazy company that is now attempting to extort money.

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Paul Vixie]

[EMAIL PROTECTED] (Paul Vixie) writes:

> in the example i posted earlier, i included some numbers from one member of
> the "f troop", which showed ~21M packets from rfc1918 space over the course
> of ~106 days.  that's 241 queries per second.  on only one host of many.
> granted it's not much as a percentage of the total, but it's not "a few".

sorry, i mixed up my numbers.  it's only a trickle of queries per second at
any given f-root node.  but it sure adds up when you look at all f-root nodes
together, or when you look at all root servers together.
-- 
Paul Vixie

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Patrick W Gilmore]

On Aug 18, 2004, at 6:46 PM, Richard A Steenbergen wrote:
On Wed, Aug 18, 2004 at 06:12:38PM -0400, Jared Mauch wrote:
	Anyone that isn't working on this (even slowly) is helping
contribute to part of the problem/mess of rfc1918 sourced packets 
leaking
to the internet.
Tell it to the unfortunate number of people manufacturing customer edge
aggregation boxes which still don't support uRPF. :)
I think he just did.
And, perhaps more importantly, he is telling the people who are 
considering buying such hardware.

And, perhaps most importantly, people should tell transit providers 
they are considering purchasing transit from that this is unacceptable. 
 (You can consider this my personal notice to all transit providers.)

--
TTFN,
patrick

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Paul Vixie]

> > > > Is it really enough traffic that you, as a root server operator,
> > > > can't just suck it up and deal? Sure there are going to be a few
> > > > folks who are misconfigured, but I can't imagine that it is enough
> > > > to cause operational issues.

a few folks?  no.  if it was a few packets now and then i'd say no problem.
in the example i posted earlier, i included some numbers from one member of
the "f troop", which showed ~21M packets from rfc1918 space over the course
of ~106 days.  that's 241 queries per second.  on only one host of many.
granted it's not much as a percentage of the total, but it's not "a few".

furthermore, leaking rfc1918 is evidence that a network would also allow ip
spoofing, and probably is being used as a spoofed-source attack vector.  if
we clean up the problems we can prove we're having, then it will make the
remaining problems stand out a little better against an uncluttered background.
(but i'm sure that a community as robustly steeped in operations philosophy
as NANOG doesn't need me to tell them something so elementary-- sorry to 
"preach to the choir" as it were.)

>   Let me put it the ultimate way:
> ...
>   We (AS2914) attempt to insure that packets our customers pass
> to our network are from address space they are registered/authorized
> to pass.

thank you!

>   I know that AT&T (AS7018) does this as well with their customers.

thank you at&t!

>   Anyone that isn't working on this (even slowly) is helping
> contribute to part of the problem/mess of rfc1918 sourced packets leaking
> to the internet.

yes.

>   While there is a cost on operators of services (eg: Paul/ISC in
> f.root ops), it's not just the 1918 sourced packets you should be worried
> about, it's the people spoofing others ips...  While enabling u-rpf in
> one of our pops, i was watching what sources were coming in on the links
> to insure that we were not dropping the wrong packets, or the customers
> didn't need to really source packets from those ranges.. a lot of
> machines were spewing packets from random ips on the other side of the
> world (europe, asia) that should not have been coming from machines in
> the US behind some random T1 customer..

encore, encore!

if BCP38 is too long and complicated for your management to understand when
you ask for additional staff or equipment to turn on u-rpf, there's a shorter
(4 pages) executive-compatible document that you should print out and staple
to your requisition, at ,
from which i shall hum a few bars since the "icann" might be a turnoff:

   SECSAC   Paul Vixie, ISC
   SAC 004 October 17, 2002

  Securing the Edge

   Abstract

  At every edge of the global Internet are the hosts who generate and
  consume the packet flows which, together, form the overall Internet
  traffic load.  By number, most of these hosts are not secure, leading
  to dangerous, untraceable traffic flows which can be used to attack
  other hosts.  This memo describes some of the security problems "at
  the edge" and makes some recommendations for improvement.

   ...

yes, this really was published four days before a widely publicized global
DDoS against the root name server system, which was documented at
.  this was just a coincidence,
but as long as i'm humming songs for y'all, here's the top of this one:

   ISC/UMD/Cogent  Paul Vixie, ISC
   OCTOBER21.TXT Gerry Sneeringer, UMD
   November 24, 2002Mark Schleifer, Cogent

Events of 21-Oct-2002

   Abstract

  On October 21, 2002, the Internet Domain Name System's root name
  servers sustained a denial of service attack.  This report explains
  the nature and impact of the attack, based on previously and
  publically available information.

   ...

happy homework!  and please keep those rfc1918-related / u-rpf related
cards and letters coming.
-- 
Paul Vixie

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Richard A Steenbergen]

On Wed, Aug 18, 2004 at 06:12:38PM -0400, Jared Mauch wrote:
> 
>   Anyone that isn't working on this (even slowly) is helping
> contribute to part of the problem/mess of rfc1918 sourced packets leaking
> to the internet.

Tell it to the unfortunate number of people manufacturing customer edge 
aggregation boxes which still don't support uRPF. :)

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Specialty Technical Publishers

[Mike Lewinski]

Has anyone else has run into these scumbags? Sometime last winter I 
received a call along the lines of "We'd like to send you some materials 
to review". Well, they sent some "Internet Law encyclopedia" along with 
an invoice for ~$700. Of course, there was no cost mentioned in the 
sales call- for all I knew they were going to send me a brochure about 
their product. I can say with 100% certainty that I would never have 
authorized them to send me something like this had they mentioned the 
cost without much further discussion as to what I was receiving.

This is just a general heads-up to a sleazy business practice for a 
sleazy company that is now attempting to extort money.

Re: OT - 3 Free Gmail invites

[Brett]

WOW!  Overwhelming response.  Haven't sent them all out yet, but all
accounted for.

Brett

On Wed, 18 Aug 2004 13:51:43 -0700, Brett <[EMAIL PROTECTED]> wrote:
> I've got a few to give out as well.  Email me off-list and if I have
> any left, I'll send an invite.
> 
> Brett
> 
> On Wed, 18 Aug 2004 16:43:30 -0400, Joshua Brady <[EMAIL PROTECTED]> wrote:
> >
> > All gone
> >
>

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Jared Mauch]

On Wed, Aug 18, 2004 at 05:31:47PM -0400, Richard A Steenbergen wrote:
> 
> On Wed, Aug 18, 2004 at 02:18:32PM -0700, David A. Ulevitch wrote:
> > 
> > 
> > 
> > 
> > > Is it really enough traffic that you, as a root server operator, can't
> > > just suck it up and deal? Sure there are going to be a few folks who are
> > > misconfigured, but I can't imagine that it is enough to cause operational
> > > issues.
> > 
> > No, no operational issues at all from RFC1918 space
> > 
> > http://www.as112.net/  (just to drop the most well documented example...)
> 
> That looks like a 1918 issue to me... Lets be clear about the difference 
> between a DNS query for 1918 space and a DNS query sources from 1918 space 
> which can never be returned too.
> 
> Yes I'm sure it is annoying, but the questions are:
> 
> How much EXTRA load does it really place on the rootservers?
> Is it really so much load that you can't just chalk it up to a normal 
> part of the service being provided?
> 
> Or to put it another way:
> 
> How much computing power would I need to buy you so that I never have to 
> hear complaints about queries from 1918 space on a mailing list again? :)

Let me put it the ultimate way:

How many routers, linecards, configs, etc.. need to be
upgraded to insure that there is source address validation.

I want to insure that every packet I deliver to my
end-customers is from a real host on the other side.  Even if it's
0wned, i want to pass that packet until such time as our
security team is notified and works to mitigate it.

We (AS2914) attempt to insure that packets our customers pass
to our network are from address space they are registered/authorized
to pass.

I know that AT&T (AS7018) does this as well with their
customers.

Anyone that isn't working on this (even slowly) is helping
contribute to part of the problem/mess of rfc1918 sourced packets leaking
to the internet.

While there is a cost on operators of services (eg: Paul/ISC
in f.root ops), it's not just the 1918 sourced packets you should
be worried about, it's the people spoofing others ips...  While
enabling u-rpf in one of our pops, i was watching what sources were
coming in on the links to insure that we were not dropping
the wrong packets, or the customers didn't need to really source
packets from those ranges.. a lot of machines were spewing packets
from random ips on the other side of the world (europe, asia) that should
not have been coming from machines in the US behind some random T1 customer..

Router#deb ip cef drops ?  
  rpf Packets dropped by CEF Unicast RPF

- jared

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

Re: Phishing (Was Re: WashingtonPost computer security stories)

[Brett]

I received a few messages as well, one with US Bank, which I don't
have an account with, and they both had images attached.  The image
was displayed, without any external connection.

As far as fighting abuse with abuse, it's not *always* a bad idea.  If
the databases are filled with bad entries, it will be too costly to
sort through valid data.  Other people will cease to purchase
information from the phisher because of unreliable data, or less will
be paid.  Either way, there will be less money in the particular
method and less of an incentive.  It will not stop phishing totally,
but why make it easier?  If you've got some extra time to write
something, then go for it.

As far as legal concerns, there is no law against lying to someone
that is trying to steal from you.

-b

On Tue, 17 Aug 2004 09:06:30 -0400 (EDT), Tim Wilde <[EMAIL PROTECTED]> wrote:
> 
> On Tue, 17 Aug 2004, Eric Kuhnke wrote:
> 
> > It's a 1 line rule with mod_rewrite and apache to block
> > nonexistant or off-site http referers attempting to display
> > GIF/JPG/PNG images...  Sometimes I wonder why Citibank,
> > Paypal and others don't do this.  It would cut down on the
> > displayed authenticity level of many basic phishes.
> 
> Because many (broken) browsers/proxies/"firewalls"/etc block or forge
> referrer headers "for security" and they'd quadruple their tech support
> load with all their idiot customers using Norton Internet Security or
> other similar products calling in saying "why don't I get any images on
> the site?  waah!"  This simply isn't an option in the real world.
> 
> --
> Tim Wilde
> [EMAIL PROTECTED]
> Systems Administrator
> Dynamic Network Services, Inc.
> http://www.dyndns.org/
>

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Richard A Steenbergen]

On Wed, Aug 18, 2004 at 02:18:32PM -0700, David A. Ulevitch wrote:
> 
> 
> 
> 
> > Is it really enough traffic that you, as a root server operator, can't
> > just suck it up and deal? Sure there are going to be a few folks who are
> > misconfigured, but I can't imagine that it is enough to cause operational
> > issues.
> 
> No, no operational issues at all from RFC1918 space
> 
> http://www.as112.net/  (just to drop the most well documented example...)

That looks like a 1918 issue to me... Lets be clear about the difference 
between a DNS query for 1918 space and a DNS query sources from 1918 space 
which can never be returned too.

Yes I'm sure it is annoying, but the questions are:

How much EXTRA load does it really place on the rootservers?
Is it really so much load that you can't just chalk it up to a normal 
part of the service being provided?

Or to put it another way:

How much computing power would I need to buy you so that I never have to 
hear complaints about queries from 1918 space on a mailing list again? :)

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[David A. Ulevitch]

> Is it really enough traffic that you, as a root server operator, can't
> just suck it up and deal? Sure there are going to be a few folks who are
> misconfigured, but I can't imagine that it is enough to cause operational
> issues.

No, no operational issues at all from RFC1918 space

http://www.as112.net/  (just to drop the most well documented example...)

-davidu


   David A. Ulevitch - Founder, EveryDNS.Net
   http://david.ulevitch.com -- http://everydns.net

Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Richard A Steenbergen]

On Wed, Aug 18, 2004 at 07:57:53PM +, Paul Vixie wrote:
> 
> this seems excessive, and so i've been assuming that it was all vijay's
> fault.  but apparently it's not him.  so which one of you isn't filtering
> 1918 at your edge?  (oops, it's all of you, isn't it?)

Is it really enough traffic that you, as a root server operator, can't 
just suck it up and deal? Sure there are going to be a few folks who are 
misconfigured, but I can't imagine that it is enough to cause operational 
issues.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: OT - 3 Free Gmail invites

[Brett]

I've got a few to give out as well.  Email me off-list and if I have
any left, I'll send an invite.

Brett

On Wed, 18 Aug 2004 16:43:30 -0400, Joshua Brady <[EMAIL PROTECTED]> wrote:
> 
> All gone
>

Re: OT - 3 Free Gmail invites

[Joshua Brady]

All gone

filtering 1918 (was Re: Summary with...: Domain Name System ...)

[Paul Vixie]

> That said, I do filter 1918 at my edge.
> 
> /vijay

ok everybody, vijay says the snapshot below didn't come from him.
who wants to claim it, then?

# tcpdump -n -c 25 net 10 or net 192.168 or net 172.16.0.0/12
tcpdump: listening on fxp0
19:52:53.787244 10.9.10.250.53 > 192.5.5.241.53:  29644 MX? rogers.com. (29)
19:52:53.789098 10.9.10.250.53 > 192.5.5.241.53:  29643 A? tock.usno.navy.mil. (36)
19:52:53.790367 10.9.10.250.53 > 192.5.5.241.53:  29642 MX? nygh.on.ca. (29)
19:52:53.791023 10.9.10.250.53 > 192.5.5.241.53:  29641 MX? sympatico.ca. (31)
19:52:54.000576 10.6.166.16.35067 > 192.5.5.241.53:  51520 PTR? 
23.180.243.65.in-addr.arpa. (44) (DF)
19:52:54.000591 10.6.166.16.35067 > 192.5.5.241.53:  39692 MX? wedweb.cc. (27) (DF)
19:52:54.049835 10.21.13.50.32769 > 192.5.5.241.53:  19542 NS? . (17) (DF)
19:52:54.167651 10.1.10.8.53 > 192.5.5.241.53:  17611 PTR? 1.18.32.10.in-addr.arpa. 
(41)
19:52:54.227294 172.22.26.5.53 > 192.5.5.241.53:  5298 A? autodesk.com. (30)
19:52:54.327460 10.48.10.250.53 > 192.5.5.241.53:  29477 MX? unco.edu. (27)
19:52:54.328475 10.48.10.250.53 > 192.5.5.241.53:  29476 MX? unco.edu. (27)
19:52:54.329118 10.48.10.250.53 > 192.5.5.241.53:  29475 MX? icella.com. (29)
19:52:54.329736 10.48.10.250.53 > 192.5.5.241.53:  29474 MX? att.net. (26)
19:52:54.487335 10.40.1.29.53 > 192.5.5.241.53:  10970 [b2&3=0x400] A? 
czdm01.bauholding.com. (39)
19:52:54.490662 10.40.1.29.53 > 192.5.5.241.53:  10971 A? 
IBM-4406B6DF58E.bauholding.com. (48)
19:52:54.491791 192.168.0.2.1033 > 192.5.5.241.53:  4574 A? velu.neuro6.com. (33)
19:52:54.493123 192.168.0.2.1033 > 192.5.5.241.53:  4580 A? velu.neuro6.com. (33)
19:52:54.495051 192.168.0.2.1033 > 192.5.5.241.53:  12777 A? velu.neuro6.com. (33)
19:52:54.508596 172.23.3.39.1057 > 192.5.5.241.53:  2240 A? 
download.windowsupdate.com. (44)
19:52:54.511223 172.23.3.39.1057 > 192.5.5.241.53:  14538 A? 
download.windowsupdate.com. (44)
19:52:54.513568 172.23.3.39.1057 > 192.5.5.241.53:  6358 A? 
download.windowsupdate.com. (44)
19:52:54.527938 10.26.0.10.32769 > 192.5.5.241.53:  53702 A? nuyoo.utm.mx. (30) (DF) 
[tos 0x4] 
19:52:54.553784 192.168.192.49.47768 > 192.5.5.241.53:  34671 PTR? 
36.7.7.4.in-addr.arpa. (39) (DF)
19:52:54.605368 10.26.0.10.32769 > 192.5.5.241.53:  60698 A? uumail.unt.edu.ar. (35) 
(DF) [tos 0x4] 
19:52:54.634115 10.26.0.10.32769 > 192.5.5.241.53:  30349[|domain] (DF) [tos 0x4] 
2410 packets received by filter
0 packets dropped by kernel

note: in 106 days of uptime, this particular host inside the f-root cluster
has discarded the following:

rule#   packets   --octets-- -rule
00400   6446004428112547 deny ip from 10.0.0.0/8 to any in
00500   5874604369667080 deny ip from 172.16.0.0/12 to any in
00600   8367728546972348 deny ip from 192.168.0.0/16 to any in

this seems excessive, and so i've been assuming that it was all vijay's
fault.  but apparently it's not him.  so which one of you isn't filtering
1918 at your edge?  (oops, it's all of you, isn't it?)
-- 
Paul Vixie

OT - 3 Free Gmail invites

[Joshua Brady]

I've got 2 Gmail invites up for grabs for the first 2 to email me offlist.

[EMAIL PROTECTED]

Josh Brady

Re: Current street prices for US Internet Transit

[Niels Bakker]

* [EMAIL PROTECTED] (Deepak Jain) [Wed 18 Aug 2004, 18:52 CEST]:
> Or, perhaps the better question is. How can one justify the cost of 
> _public_ peering when fiber cross-connects are $200-$300/month each. 

Perhaps not at the site previously mentioned.

I believe fiber crossconnects are cheaper than that at the various
AMS-IX housing sites but people still choose to connect to the exchange
switch.  Bushes of private interconnects tend to quickly become
unmanageable (and no, not just those of "throw wire over wall" discussed
here some months ago - that's not allowed at any AMS-IX housing site).


> I don't think there are too many exchanges anymore that have 80+ active 
> peers. If you do participate in such an exchange, have 80 peers on it, 
> and don't exceed a single port's speed, shame on you. :)

AMS-IX has almost 200 connected parties.  Luckily hardly anybody is
trying to suck more traffic through their port than it can physically
handle.

Not everybody has a gigabit per second worth of traffic.  Some even make
do with a 10baseT connection (full duplex of course :).  Apparently
still a worthwhile proposition in a world of falling transit prices.


-- Niels.

-- 
Today's subliminal thought is: 

Re: Current street prices for US Internet Transit

[Stephen J. Wilcox]

On Wed, 18 Aug 2004, Fredy Kuenzler wrote:

> With these US street prices in mind, how can anyone justify paying
> prices of some commercial exchanges (the last offer I got from PAIX Palo
> Alto was USD 5500 per month for a FE port about a year ago, and Equinix
> Ashburn was not much cheaper). Please note: I'm not talking of the
> technical advantages of peering.

You cant, perhaps they'll realise that before they become deprecated

Steve

Re: SYN flood atacks?

[Stephen J. Wilcox]

we took around a gig of port 80 syn flooding to a customer web host, it was 
around 12-3pm utc.. ended when the customer disappeared off the net. not sure if 
this is unusual tho, theres hundreds of such attacks per day globally...

Steve

On Tue, 17 Aug 2004, [EMAIL PROTECTED] wrote:

> Sorry I didnt take the smart ass factor into account when I posted.  I have heard 
> that AOL and other mega proxies have been sending enough SYN floods (DDoS style) to 
> knock over Discover and Allstate.  I am not talking about small amounts of normal 
> traffic.
> Jason
> 
> -- Original message -- 
> 
> > 
> > 
> > On Tue, 17 Aug 2004 [EMAIL PROTECTED] wrote: 
> > > I have been hearing rumors about some SYN flood atacks on the Internet 
> > > today. Anybody hear anything? 
> > 
> > You will need to be more specific. 
> > 
> > There are syn flood attacks, icmp attacks, udp attacks, tcp attacks, dns 
> > attacks, http attacks, im attacks, ipsec attacks, etc going on every day, 
> > all day. 
> > 
> > 

Re: Current street prices for US Internet Transit

[Deepak Jain]

With these US street prices in mind, how can anyone justify paying
prices of some commercial exchanges (the last offer I got from PAIX Palo
Alto was USD 5500 per month for a FE port about a year ago, and Equinix
Ashburn was not much cheaper). Please note: I'm not talking of the
technical advantages of peering.
Or, perhaps the better question is. How can one justify the cost of 
_public_ peering when fiber cross-connects are $200-$300/month each. 
That is at least 20-40 fiber direct connects [twice that if you & your 
peers split the cost of cross-connects]. If you only need 1Gb/s of 
cross-connect capacity you can take a 3x50 switch [or use it as a 
router] and terminate all of the peering sessions on it or via 
VLAN-trunking directly on your real router [C/J/what have you]. Your 
hardware cost is marginally increased and your capacity is MANY times 
larger.

I don't think there are too many exchanges anymore that have 80+ active 
peers. If you do participate in such an exchange, have 80 peers on it, 
and don't exceed a single port's speed, shame on you. :)

DJ

Re: Current street prices for US Internet Transit

[Fredy Kuenzler]

William B. Norton wrote:
> The Cost of Internet Transit in…
> Commit  AU  SG  JP  HK  USA
> 1 Mbps  $720$625$490$185$125
> 10 Mbps $410$350$150$100$80
> 100 Mbps$325$210$110$80 $45
> 1000 Mbps   $305$115$50 $50 $30
As mentioned before, Europe is about the same as US.
With these US street prices in mind, how can anyone justify paying
prices of some commercial exchanges (the last offer I got from PAIX Palo
Alto was USD 5500 per month for a FE port about a year ago, and Equinix
Ashburn was not much cheaper). Please note: I'm not talking of the
technical advantages of peering.
Fredy Künzler
Init Seven AG, AS13030

Cisco Security Advisory: Cisco IOS Malformed OSPF Packet Causes Reload

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Cisco IOS Malformed OSPF Packet Causes Reload

Revision 1.0

For Public Release 2004 August 18 15:00 UTC (GMT)

- 

Contents

Summary
Affected Products
Details
Impact
Software Versions and Fixes
Obtaining Fixed Software
Workarounds
Exploitation and Public Announcements
Status of This Notice: FINAL
Distribution
Revision History
Cisco Security Procedures

- 

Summary
===

A Cisco device running Internetwork Operating System (IOS) and enabled for
the Open Shortest Path First (OSPF) protocol is vulnerable to a Denial of
Service (DoS) attack from a malformed OSPF packet. The OSPF protocol is not
enabled by default.

The vulnerability is only present in Cisco IOS release trains based on 12.0S,
12.2, and 12.3. Releases based on 12.0, 12.1 mainlines, and all Cisco IOS
images prior to 12.0 are not affected.

Cisco has made free software available to address this vulnerability.

There are workarounds available to mitigate the effects.

This advisory is available at 
http://www.cisco.com/warp/public/707/cisco-sa-20040818-ospf.shtml.

Affected Products
=

Vulnerable Products

This vulnerability was introduced by a code change that was committed to the
12.0S, 12.2, and 12.3 based release trains, causing these trains to be
vulnerable. All Cisco devices running a vulnerable release train and running
OSPF process are vulnerable.

Some release trains that are not vulnerable are explicitly listed below for
clarification. The release trains that are not mentioned below are not
vulnerable.

+-+
| Release Train | Vulnerable  |
|   |  Versions   |
|---+-|
| 10.x based releases   | Not |
|   | vulnerable  |
|---+-|
| 11.x based releases   | Not |
|   | vulnerable  |
|---+-|
| 12.0 based releases (except   | Not |
| for 12.0.S based releases)| vulnerable  |
|---+-|
| 12.1 based releases   | Not |
|   | vulnerable  |
|---+-|
| 12.0.S| 12.0(22)S   |
|   | and later   |
|---+-|
| 12.0.SX   | 12.0(23)SX  |
|   | and later   |
|---+-|
| 12.0.SY   | 12.0(22)SY  |
|   | and later   |
|---+-|
| 12.0.SZ   | 12.0(23)SZ  |
|   | and later   |
|---+-|
| 12.2 mainline | Not |
|   | vulnerable  |
|---+-|
| 12.2.B| 12.2(15)B   |
|   | and later   |
|---+-|
| 12.2.BC   | 12.2(15)BC  |
|   | and later   |
|---+-|
| 12.2.BX   | 12.2(15)BX  |
|   | and later   |
|---+-|
| 12.2.BZ   | 12.2(15)BZ  |
|   | and later   |
|---+-|
| 12.2.CX   | 12.2(15)CX  |
|   | and later   |
|---+-|
| 12.2.EW   | 12.2(18)EW  |
|   | and later   |
|---+-|
| 12.2.MC   | 12.2(15)MC1 |
|   | and later   |
|---+-|
| 12.2.S| 12.2(18)S   |
|   | and later   |
|---+-|
| 12.2.SE   | 12.2(18)SE  |
|   | and later   |
|---+-|
| 12.2.SV   | 12.2(18)SV  |
|   | and later   |
|---+-|
| 12.2.SW   | 12.2(18)SW  |
|   | and later   |
|---+-|
| 12.2.SZ   | 12.2(14)SZ  |
|   | and later

Re: Current street prices for US Internet Transit

[Andre Oppermann]

Deepak Jain wrote:
Have you tried running a single TCP stream over a 10 meg ethernet with 
a 5
megabit/s policer on the port? Do that, figure about what happens and
explain to the rest of the class why this single TCP stream cannot use 
all
of the 5 megabit/s itself.
That's entirely a different example. If we are talking about a stream 
that is _exactly 5Gb/s or _exactly_ 5mb/s, the policer won't be hit. In 
the example we are talking about below, an _approximately_ 5Gb/s stream 
on an _approximately_ full pipe the performance will be significantly 
better than you imply. And I have customers that do it pretty regularly 
(2 ~500Mb/s streams per GE port - telemetry data) on their equipment 
with very small buffers (3550s).
The required buffer size depends on the RTT of the TCP stream going over
it.  If you have the 3550 with small buffers and 5ms TCP RTT then everything
is well.  If you have the 3550 with small bufferns and 200ms TCP RTT you
will run into troubles.
--
Andre

Re: BGP-based blackholing/hijacking patented in Australia?

[Adrian Chadd]

On Fri, Aug 13, 2004, Bevan Slattery wrote:
> 
> Hi,
> 
> Just to ease peoples concerns, the patent has nothing to do with 
> blackholing.  A brief description of the way it works can be found here:
> 
> http://www.scamslam.com/ScamSlam/whatis.shtml
> 
> We have not disclosed the site address to the "public" at this stage, the 
> text of the site is only draft form for the purposes of editing and needs 
> to be "polished".  Perhaps the article wasn't as articulate in conveying 
> this, but I'm sure you appreciate journalists sometimes don't get it right 
> :)

Bevan,

Would you be willing to export this database as a list of URLs
rather than a list of IPs?

I, for one, would like to run this on centralised proxy servers
and build ACLs for devices such as proxy servers and firewalls.
I don't want to speak BGP.  A text file - whether its one line
per host, or some well-formatted and documented XML database -
would allow people to decide the best way to implement it with
their network.

It would be nice if it were hostname vs IP - it both stops
the possibility of entire ISPs being wiped out by IP
blocks and it also allows us to track the DNS changes
as the phishing people start running things in a similar
way to the spammers do.

It would also be nice if you were able to include some
metadata on what the scam is. It would allow people to
choose exactly which to include in our local filters.


Thankyou.





Adrian

-- 
Adrian ChaddI'm only a fanboy if
<[EMAIL PROTECTED]> I emailed Wesley Crusher.