Re: Postmaster @ vtext.com (or what are best practice to send SMS these days)

[Henning Brauer]

* David Ulevitch <[EMAIL PROTECTED]> [2008-04-16 19:18]:
> What else are operators doing to get the pages out when things go wonky?

a UMTS/3G card, that just attaches a usb controller (ohci) and a 
usb-serial converter behind it (ubsa), and a "modem" behind that takes 
AT commands. the commands are even somewhat standardized. Add a bit of 
kermit and shell scripting around and you have a very reliable 
out-of-band notification mechanism.

-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Re: amazonaws.com?

[Joe Loiacono]

Barry Shein <[EMAIL PROTECTED]> wrote on 05/28/2008 11:08:56 PM:

> I'm still curious what a typical $ sale is on one of these cloud
> compute clusters, in orders of magnitude, $1, $10, $100, $1000, ...?

Not sure what a typical sale looks like, but

Single virtual instance: ~ $72/month

from AWS:

Storage
$0.15 per GB-Month of storage used

Data Transfer
$0.100 per GB - all data transfer in

$0.170 per GB - first 10 TB / month data transfer out
$0.130 per GB - next 40 TB / month data transfer out
$0.110 per GB - next 100 TB / month data transfer out
$0.100 per GB - data transfer out / month over 150 TB 

Requests
$0.01 per 1,000 PUT, POST, or LIST requests
$0.01 per 10,000 GET and all other requests*
 * No charge for delete requests 

Joe

Announcing iBGPlay: visualization of BGP events

[Maurizio Pizzonia]

iBGPlay is a free tool that graphically displays and animates BGP routing
announcements (http://www.ibgplay.org). iBGPlay will be presented at NANOG43 on 
June 3, 2008.


For those that are familiar with BGPlay (http://bgplay.routeviews.org/bgplay/,
http://www.ris.ripe.net/bgplay):
- iBGPlay offers a similar service showing BGP updates received by the border 
routers of the ISP that uses it. Hence, it is somehow complementary to BGPlay.
- BGP updates received by different border routers of the ISP are shown in an 
integrated view.


Maurizio Pizzonia
iBGPlay team

--
_Maurizio Pizzonia___
 Dipartimento di Informatica e Automazione   ph. +39-06-5733-3311
 Universita` Roma Trefax +39-06-5733-3211
 http://www.dia.uniroma3.it/~pizzonia

Re: amazonaws.com?

[Dorn Hetzel]

There is a really huge difference in the ease with which payment from a
credit card can be reversed if fraudulent, and the amount of effort
necessary to reverse a wire transfer. I won't go so far as to say that
reversing a wire transfer is impossible, but I would claim it's many orders
of magnitude harder than the credit card reversal.

A mere "court subpoena" wouldn't even be remotely sufficient.  The person
wanting their money back would pretty much have to sue for it and win.
Heck, people that get scammed and send their money via western union can't
even get their money back...  People who sell physical goods that get
shipped internationally to places where they can't get them back from have
been dealing with irrevocable payment forms for a long, long time, and those
are generally wire transfers.

Once that guy in Frackustan has my widgets, I need to make darn sure he
can't take his money back :)

So, yeah, there would be some customers for whom the couple of business
hours it take their wire to go through (that's a pretty typical time from my
actual experience) would be longer than they would want to wait for their
port 25 or other "risky" service to be enabled, but really, how many is that
going to be.  We're not talking about the wait for ordinary customers who
don't need those particular services that tend to be problem children, and
we're not talking about existing accounts of long standing, just about a
barrier for the drive-by customer who wants to use services and then not pay
the cost when they violate the AUP...

On Wed, May 28, 2008 at 11:53 PM, Peter Beckman <[EMAIL PROTECTED]> wrote:

> On Wed, 28 May 2008, Barry Shein wrote:
>
>  On May 28, 2008 at 21:43 [EMAIL PROTECTED] (Peter Beckman) wrote:
>> > On Wed, 28 May 2008, Dorn Hetzel wrote:
>> >
>> > > I would think that simply requiring some appropriate amount of
>> irrevocable
>> > > funds (wire transfer, etc) for a deposit that will be forfeited in the
>> case
>> > > of usage in violation of AUP/contract/etc would be both sufficient and
>> not
>> > > excessive for allowing port 25 access, etc.
>> >
>> >   Until you find out that the source of those supposedly irrevocable
>> funds
>> >   was stolen or fraudulent, and you have some sort of court subpoena to
>> give
>> >   it back.
>> >
>> >   I don't believe there is a way for you to outwit the scammer/spammer
>> by
>> >   making them pay more of their or someone elses money.  If you have
>> what
>> >   they need, they'll find a way to trick you into giving it to them.
>>
>> Are you still trying to prove that Amazon, Dell, The World, etc can't
>> possibly work?
>>
>
>  Amazon and Dell ship physical goods.  Amazon Web Services sells services,
>  as do I.  Services are commonly enabled and activated immediately after
>  payment or verification of a valid credit card, as is often expected by
>  the customer immediately after payment.  Shipment of physical goods will
>  almost always take at least 24 hours, often longer, enabling more thorough
>  checks of credit, however they might do it.
>
>  And even with the extra time to review the transaction and attempt to
>  detect fraud, I'm confident Amazon and Dell lose millions per year due to
>  fraud.  The reality is that the millions they lose to fraud doesn't affect
>  us because a Blu-Ray player purchased with a stolen credit card doesn't
>  send spam or initiate DOS attacks.
>
>  At least not yet; those Blu-Ray players do have an ethernet port.
>
>  By your reasoning why don't the spammers just empty out Amazon's (et
>> al) warehouses and retire! Oh right, they'd have to sell it all over
>> the internet which'd mean taking credit cards...
>>
>
>  Now you're just being rediculous.  Or sarcastic.  :-)
>
>  I am a big, big fan of assessing charges for AUP abuse and making some
>> realistic attempt to try to make sure it's collectible, and otherwise
>> make some attempt to know who you're doing business with.
>>
>
>  Charging whom?  The spammer who pays your extra AUP abuse charges with
>  stolen paypal accounts, credit cards, and legit bank accounts funded by
>  money stolen from paypal accounts and transferred from stolen credit
>  cards?
>
>  If you are taking card-not-present credit card transactions over the
>  Internet or phone, and not shipping physical goods but providing services,
>  in my experience the merchant gets screwed, no matter how much money you
>  might have charged for the privilege of using port 25 or violating AUPs.
>  That money you collected and believed was yours and was in your bank
>  account can be taken out just as easily 6 months later, after the lazy
>  card holder finally reviews his credit card bill, sees unrecognized
>  charges and says "This is fraudulent!"  And there you are, without your
>  money.
>
>  Getting someone to fax their ID in takes extra time and resources, and
>  means it might be hours before you get your account "approved," and for
>  some service providers, part of the value of the service is th

Re: amazonaws.com?

[Al Iverson]

On Wed, May 28, 2008 at 11:08 PM, Barry Shein <[EMAIL PROTECTED]> wrote:

> I am a big, big fan of assessing charges for AUP abuse and making some
> realistic attempt to try to make sure it's collectible, and otherwise
> make some attempt to know who you're doing business with.

Just out of curiosity, what stats can you make available as far as:
- How often you assess this AUP abuse fee?
- How often it is successfully collected?
- How successful are chargebacks against that fee?

I've heard lots of anti-abuse folks opine that this helps with spam
and other abuse prevention and cleanup, but I've never seen it in
practice before. I've also heard multiple ISP folks talk about it
being unenforceable. And from what I know from working for an
e-commerce service provider in the past, it sounds like a chargeback
magnet that could even endanger the merchant account of anybody who
uses it more than once.

Regards,
Al Iverson
-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.

Re: amazonaws.com?

[Joel Jaeggli]

Dorn Hetzel wrote:

There is a really huge difference in the ease with which payment from a
credit card can be reversed if fraudulent, and the amount of effort
necessary to reverse a wire transfer. I won't go so far as to say that
reversing a wire transfer is impossible, but I would claim it's many orders
of magnitude harder than the credit card reversal.


To paraphrase one of my colleagues from the user interaction world:

"The key to offering a compelling service is minimising
transaction hassles."

I encourage all my competitors to implement inconvenient hard to use 
payment methods



A mere "court subpoena" wouldn't even be remotely sufficient.  The person
wanting their money back would pretty much have to sue for it and win.
Heck, people that get scammed and send their money via western union can't
even get their money back...  People who sell physical goods that get
shipped internationally to places where they can't get them back from have
been dealing with irrevocable payment forms for a long, long time, and those
are generally wire transfers.

Once that guy in Frackustan has my widgets, I need to make darn sure he
can't take his money back :)

So, yeah, there would be some customers for whom the couple of business
hours it take their wire to go through (that's a pretty typical time from my
actual experience) would be longer than they would want to wait for their
port 25 or other "risky" service to be enabled, but really, how many is that
going to be.  We're not talking about the wait for ordinary customers who
don't need those particular services that tend to be problem children, and
we're not talking about existing accounts of long standing, just about a
barrier for the drive-by customer who wants to use services and then not pay
the cost when they violate the AUP...

On Wed, May 28, 2008 at 11:53 PM, Peter Beckman <[EMAIL PROTECTED]> wrote:


On Wed, 28 May 2008, Barry Shein wrote:

 On May 28, 2008 at 21:43 [EMAIL PROTECTED] (Peter Beckman) wrote:

On Wed, 28 May 2008, Dorn Hetzel wrote:


I would think that simply requiring some appropriate amount of

irrevocable

funds (wire transfer, etc) for a deposit that will be forfeited in the

case

of usage in violation of AUP/contract/etc would be both sufficient and

not

excessive for allowing port 25 access, etc.

  Until you find out that the source of those supposedly irrevocable

funds

  was stolen or fraudulent, and you have some sort of court subpoena to

give

  it back.

  I don't believe there is a way for you to outwit the scammer/spammer

by

  making them pay more of their or someone elses money.  If you have

what

  they need, they'll find a way to trick you into giving it to them.

Are you still trying to prove that Amazon, Dell, The World, etc can't
possibly work?


 Amazon and Dell ship physical goods.  Amazon Web Services sells services,
 as do I.  Services are commonly enabled and activated immediately after
 payment or verification of a valid credit card, as is often expected by
 the customer immediately after payment.  Shipment of physical goods will
 almost always take at least 24 hours, often longer, enabling more thorough
 checks of credit, however they might do it.

 And even with the extra time to review the transaction and attempt to
 detect fraud, I'm confident Amazon and Dell lose millions per year due to
 fraud.  The reality is that the millions they lose to fraud doesn't affect
 us because a Blu-Ray player purchased with a stolen credit card doesn't
 send spam or initiate DOS attacks.

 At least not yet; those Blu-Ray players do have an ethernet port.

 By your reasoning why don't the spammers just empty out Amazon's (et

al) warehouses and retire! Oh right, they'd have to sell it all over
the internet which'd mean taking credit cards...


 Now you're just being rediculous.  Or sarcastic.  :-)

 I am a big, big fan of assessing charges for AUP abuse and making some

realistic attempt to try to make sure it's collectible, and otherwise
make some attempt to know who you're doing business with.


 Charging whom?  The spammer who pays your extra AUP abuse charges with
 stolen paypal accounts, credit cards, and legit bank accounts funded by
 money stolen from paypal accounts and transferred from stolen credit
 cards?

 If you are taking card-not-present credit card transactions over the
 Internet or phone, and not shipping physical goods but providing services,
 in my experience the merchant gets screwed, no matter how much money you
 might have charged for the privilege of using port 25 or violating AUPs.
 That money you collected and believed was yours and was in your bank
 account can be taken out just as easily 6 months later, after the lazy
 card holder finally reviews his credit card bill, sees unrecognized
 charges and says "This is fraudulent!"  And there you are, without your
 money.

 Getting someone to fax their ID in takes extra time and resources, and
 means it might be hours before you 

RE: amazonaws.com?

[Matthew Huff]

The financial services world felt the same pre-9/11. Since then FINRA and SEC 
regulations enforce "Know Your Customer" rules that require extensive record 
keeping. The regulations now are quite burdensome. Given that usage of "cloud" 
resources could be used for DDOS and other illegal activities, I wonder how 
long it will take companies to realize that if they don't do a good job of self 
policing, the result will be something they would prefer not to have happen.


Matthew Huff   | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
www.otaotr.com | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139

-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 29, 2008 9:09 AM
To: Dorn Hetzel
Cc: nanog@nanog.org
Subject: Re: amazonaws.com?

Dorn Hetzel wrote:
> There is a really huge difference in the ease with which payment from a
> credit card can be reversed if fraudulent, and the amount of effort
> necessary to reverse a wire transfer. I won't go so far as to say that
> reversing a wire transfer is impossible, but I would claim it's many orders
> of magnitude harder than the credit card reversal.

To paraphrase one of my colleagues from the user interaction world:

"The key to offering a compelling service is minimising
transaction hassles."

I encourage all my competitors to implement inconvenient hard to use 
payment methods

> A mere "court subpoena" wouldn't even be remotely sufficient.  The person
> wanting their money back would pretty much have to sue for it and win.
> Heck, people that get scammed and send their money via western union can't
> even get their money back...  People who sell physical goods that get
> shipped internationally to places where they can't get them back from have
> been dealing with irrevocable payment forms for a long, long time, and those
> are generally wire transfers.
> 
> Once that guy in Frackustan has my widgets, I need to make darn sure he
> can't take his money back :)
> 
> So, yeah, there would be some customers for whom the couple of business
> hours it take their wire to go through (that's a pretty typical time from my
> actual experience) would be longer than they would want to wait for their
> port 25 or other "risky" service to be enabled, but really, how many is that
> going to be.  We're not talking about the wait for ordinary customers who
> don't need those particular services that tend to be problem children, and
> we're not talking about existing accounts of long standing, just about a
> barrier for the drive-by customer who wants to use services and then not pay
> the cost when they violate the AUP...
> 
> On Wed, May 28, 2008 at 11:53 PM, Peter Beckman <[EMAIL PROTECTED]> wrote:
> 
>> On Wed, 28 May 2008, Barry Shein wrote:
>>
>>  On May 28, 2008 at 21:43 [EMAIL PROTECTED] (Peter Beckman) wrote:
 On Wed, 28 May 2008, Dorn Hetzel wrote:

> I would think that simply requiring some appropriate amount of
>>> irrevocable
> funds (wire transfer, etc) for a deposit that will be forfeited in the
>>> case
> of usage in violation of AUP/contract/etc would be both sufficient and
>>> not
> excessive for allowing port 25 access, etc.
   Until you find out that the source of those supposedly irrevocable
>>> funds
   was stolen or fraudulent, and you have some sort of court subpoena to
>>> give
   it back.

   I don't believe there is a way for you to outwit the scammer/spammer
>>> by
   making them pay more of their or someone elses money.  If you have
>>> what
   they need, they'll find a way to trick you into giving it to them.
>>> Are you still trying to prove that Amazon, Dell, The World, etc can't
>>> possibly work?
>>>
>>  Amazon and Dell ship physical goods.  Amazon Web Services sells services,
>>  as do I.  Services are commonly enabled and activated immediately after
>>  payment or verification of a valid credit card, as is often expected by
>>  the customer immediately after payment.  Shipment of physical goods will
>>  almost always take at least 24 hours, often longer, enabling more thorough
>>  checks of credit, however they might do it.
>>
>>  And even with the extra time to review the transaction and attempt to
>>  detect fraud, I'm confident Amazon and Dell lose millions per year due to
>>  fraud.  The reality is that the millions they lose to fraud doesn't affect
>>  us because a Blu-Ray player purchased with a stolen credit card doesn't
>>  send spam or initiate DOS attacks.
>>
>>  At least not yet; those Blu-Ray players do have an ethernet port.
>>
>>  By your reasoning why don't the spammers just empty out Amazon's (et
>>> al) warehouses and retire! Oh right, they'd have to sell it all over
>>> the internet which'd mean taking credit cards...
>>>
>>  Now you're just being rediculous.  Or sarcastic.  :-)
>>
>>  I am a big, big fan of assessing charges for AUP abuse and making some
>>> realistic attempt to

RE: IOS Rookit: the sky isn't falling (yet)

[Fred Reimer]

The conversation shifted to breaking MD5 because it was mentioned that one
way to prevent the installation of cracked IOS images was to include some
sort of DRM or trusted computing chip in new hardware, and have Cisco sign
their IOS images (supposedly even the boot EEPROM).  This wouldn't be DRM in
the sense of DVD's, where they don't want everyone to be able to decode the
disk, so must come up with some scheme where they provide the decryption key
that is itself decrypted with a private key which all of the DVD players
have the public key for, hence could be relatively easily broken (just
extract the public key from the player, which was what was done for HD-DVD.
In other words, attacking the crypto scheme instead of the algorithm.  Cisco
would presumably want everyone to be able to read the file, just sign it
with their private key.  So how do you sign an IOS image?  Most crypto
schemes work by generating a MD5 hash of the data, and then signing the MD5
hash, not signing the whole IOS image, which would be encrypting the whole
thing.  Decrypting an IOS image sized data block with the RSA algorithm
would presumably take too long, so just the hash is signed.  If the signed
hash matches the hash you compute when loading the image it's a good image,
so the boot ROM would load the code.  Once loaded, it would check the
signature (of the hash) on any new boot ROM loaded so that attackers could
not use that vector.

For what it's worth, encrypting the whole file is still not normally done by
encrypting with the RSA public key of the destination.  Rather, another
symmetric protocol is used, such as 3DES or IDEA or something, and they key
for that protocol is encrypted with RSA.  The private key in this case would
be located... on the new Cisco hardware.  So, much like breaking HD-DVD
crypto scheme this could be broken also.  However, I don't think it is the
goal to encrypt the IOS code, just ensure that it is valid code from Cisco,
so an appropriate hash should do just fine.

So the only easy way to attack this is the MD5 hash.  We have a know
plaintext (the IOS code) and the hash.  It is not trivial to be able to make
changes in the code and maintain the same hash value, but there has been at
least limited success in doing so.  If they can change the code and fiddle
with the help text in some obscure feature no one regularly uses and
generate the same hash then viola, access.

That's how we got onto breaking MD5.

However, if there is a known vulnerability, to however few people, in IOS
where there is a buffer overflow or something else where remote code can be
executed, this presumably could overwrite the IOS code running on the box
and bypass the code-checking hardware.  It may not be possible to replace
the boot ROM, because presumably the new hardware would check the ROM code
hash before loading it and also presumably the ROM code does not have quite
as much text messages that can be changed to generate the same hash value,
thereby bypassing the security checks.  So in this scenario rooted IOS would
only exist transiently; a reboot would load the known good code again (or
brick the box if "bad" ROMMON were burned).


Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697

> -Original Message-
> From: Gadi Evron [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 12:21 AM
> To: Steven M. Bellovin
> Cc: nanog@nanog.org
> Subject: Re: IOS Rookit: the sky isn't falling (yet)
> 
> On Thu, 29 May 2008, Steven M. Bellovin wrote:
> > On Wed, 28 May 2008 10:37:05 +0100
> > <[EMAIL PROTECTED]> wrote:
> >
> >>> So let's see - if you had a billion CPUs in your botnet, and
> >>> each one could go at a billion to the second, you still need
> >>> 2**69 seconds or 449,235,776,528,695 years.  Not bad - only
> >>> 10,000 times the amount of time this planet has been around,
> >>> so yeah, that's the way they'll attack all right.
> >>
> >> I didn't say that. I said that they are starting with an IOS image
> >> in which there are some small number of bytes which they can
> possibly
> >> change and still have a functional image. So it is likely that they
> >> will brute force that by computing an MD5 hash on all variations of
> >> those few bytes. It's like winning the lottery, you only *NEED* to
> >> buy one ticket. No matter how slim the chances are of bad guys
> winning
> >> that lottery, it is no excuse for ignoring the possibility that an
> >> MD5 hash check may not be proof that you have an original image.
> >>
> > Did you even look at Valdis' arithmetic?  It *won't work*.  It isn't
> > "likely" that they'll try anything with that low a chance of success.
> > As for "no matter how slim the chances" -- if you want to have even a
> > vague chance of succeeding before Sol turns into a red giant, you're
> > going to have to devote enormous resources to the project.
> (Actually,
> > I don't think you can succeed even then, not by brute force -- there
> > aren't 

Re: amazonaws.com?

[Dorn Hetzel]

Oh, come on...  Businesses buy services every day that have to be paid for
by methods like wire transfer.  We're not talking about making it the only
payment method, just the method for deposits for "risky" services.  I wonder
what percentage of Amazon E2C customers even want outbound port 25 access
anyway.  Of those that do want port 25 access, how many are going to wind up
being more trouble than they are worth?

And it's not really central to this conversation, but I don't think Amazon
is in *any* danger with respect to their merchant account, almost no matter
what they do :)


On Thu, May 29, 2008 at 9:08 AM, Joel Jaeggli <[EMAIL PROTECTED]> wrote:

> Dorn Hetzel wrote:
>
>> There is a really huge difference in the ease with which payment from a
>> credit card can be reversed if fraudulent, and the amount of effort
>> necessary to reverse a wire transfer. I won't go so far as to say that
>> reversing a wire transfer is impossible, but I would claim it's many
>> orders
>> of magnitude harder than the credit card reversal.
>>
>
> To paraphrase one of my colleagues from the user interaction world:
>
>"The key to offering a compelling service is minimising
>transaction hassles."
>
> I encourage all my competitors to implement inconvenient hard to use
> payment methods
>
>
>  A mere "court subpoena" wouldn't even be remotely sufficient.  The person
>> wanting their money back would pretty much have to sue for it and win.
>> Heck, people that get scammed and send their money via western union can't
>> even get their money back...  People who sell physical goods that get
>> shipped internationally to places where they can't get them back from have
>> been dealing with irrevocable payment forms for a long, long time, and
>> those
>> are generally wire transfers.
>>
>> Once that guy in Frackustan has my widgets, I need to make darn sure he
>> can't take his money back :)
>>
>> So, yeah, there would be some customers for whom the couple of business
>> hours it take their wire to go through (that's a pretty typical time from
>> my
>> actual experience) would be longer than they would want to wait for their
>> port 25 or other "risky" service to be enabled, but really, how many is
>> that
>> going to be.  We're not talking about the wait for ordinary customers who
>> don't need those particular services that tend to be problem children, and
>> we're not talking about existing accounts of long standing, just about a
>> barrier for the drive-by customer who wants to use services and then not
>> pay
>> the cost when they violate the AUP...
>>
>> On Wed, May 28, 2008 at 11:53 PM, Peter Beckman <[EMAIL PROTECTED]>
>> wrote:
>>
>>  On Wed, 28 May 2008, Barry Shein wrote:
>>>
>>>  On May 28, 2008 at 21:43 [EMAIL PROTECTED] (Peter Beckman) wrote:
>>>
 On Wed, 28 May 2008, Dorn Hetzel wrote:
>
>  I would think that simply requiring some appropriate amount of
>>
> irrevocable

> funds (wire transfer, etc) for a deposit that will be forfeited in the
>>
> case

> of usage in violation of AUP/contract/etc would be both sufficient and
>>
> not

> excessive for allowing port 25 access, etc.
>>
>  Until you find out that the source of those supposedly irrevocable
>
 funds

>  was stolen or fraudulent, and you have some sort of court subpoena to
>
 give

>  it back.
>
>  I don't believe there is a way for you to outwit the scammer/spammer
>
 by

>  making them pay more of their or someone elses money.  If you have
>
 what

>  they need, they'll find a way to trick you into giving it to them.
>
 Are you still trying to prove that Amazon, Dell, The World, etc can't
 possibly work?

   Amazon and Dell ship physical goods.  Amazon Web Services sells
>>> services,
>>>  as do I.  Services are commonly enabled and activated immediately after
>>>  payment or verification of a valid credit card, as is often expected by
>>>  the customer immediately after payment.  Shipment of physical goods will
>>>  almost always take at least 24 hours, often longer, enabling more
>>> thorough
>>>  checks of credit, however they might do it.
>>>
>>>  And even with the extra time to review the transaction and attempt to
>>>  detect fraud, I'm confident Amazon and Dell lose millions per year due
>>> to
>>>  fraud.  The reality is that the millions they lose to fraud doesn't
>>> affect
>>>  us because a Blu-Ray player purchased with a stolen credit card doesn't
>>>  send spam or initiate DOS attacks.
>>>
>>>  At least not yet; those Blu-Ray players do have an ethernet port.
>>>
>>>  By your reasoning why don't the spammers just empty out Amazon's (et
>>>
 al) warehouses and retire! Oh right, they'd have to sell it all over
 the internet which'd mean taking credit cards...

   Now you're just being rediculous.  Or sarcastic.  :-)
>>>
>>>  I am a big, big fan of asses

Re: amazonaws.com?

[Dorn Hetzel]

Yeah, there was a day when anyone could buy a pickup truck full of ammonium
nitrate fertilizer from a random feed store and not attract any attention at
all, now, maybe not.  Just like port 25, it has plenty of legitimate uses,
and some more problematic ones.

On Thu, May 29, 2008 at 9:14 AM, Matthew Huff <[EMAIL PROTECTED]> wrote:

> The financial services world felt the same pre-9/11. Since then FINRA and
> SEC regulations enforce "Know Your Customer" rules that require extensive
> record keeping. The regulations now are quite burdensome. Given that usage
> of "cloud" resources could be used for DDOS and other illegal activities, I
> wonder how long it will take companies to realize that if they don't do a
> good job of self policing, the result will be something they would prefer
> not to have happen.
>
> 
> Matthew Huff   | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> www.otaotr.com | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:   914-460-4139
>
> -Original Message-
> From: Joel Jaeggli [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 9:09 AM
> To: Dorn Hetzel
> Cc: nanog@nanog.org
> Subject: Re: amazonaws.com?
>
> Dorn Hetzel wrote:
> > There is a really huge difference in the ease with which payment from a
> > credit card can be reversed if fraudulent, and the amount of effort
> > necessary to reverse a wire transfer. I won't go so far as to say that
> > reversing a wire transfer is impossible, but I would claim it's many
> orders
> > of magnitude harder than the credit card reversal.
>
> To paraphrase one of my colleagues from the user interaction world:
>
>"The key to offering a compelling service is minimising
>transaction hassles."
>
> I encourage all my competitors to implement inconvenient hard to use
> payment methods
>
> > A mere "court subpoena" wouldn't even be remotely sufficient.  The person
> > wanting their money back would pretty much have to sue for it and win.
> > Heck, people that get scammed and send their money via western union
> can't
> > even get their money back...  People who sell physical goods that get
> > shipped internationally to places where they can't get them back from
> have
> > been dealing with irrevocable payment forms for a long, long time, and
> those
> > are generally wire transfers.
> >
> > Once that guy in Frackustan has my widgets, I need to make darn sure he
> > can't take his money back :)
> >
> > So, yeah, there would be some customers for whom the couple of business
> > hours it take their wire to go through (that's a pretty typical time from
> my
> > actual experience) would be longer than they would want to wait for their
> > port 25 or other "risky" service to be enabled, but really, how many is
> that
> > going to be.  We're not talking about the wait for ordinary customers who
> > don't need those particular services that tend to be problem children,
> and
> > we're not talking about existing accounts of long standing, just about a
> > barrier for the drive-by customer who wants to use services and then not
> pay
> > the cost when they violate the AUP...
> >
> > On Wed, May 28, 2008 at 11:53 PM, Peter Beckman <[EMAIL PROTECTED]>
> wrote:
> >
> >> On Wed, 28 May 2008, Barry Shein wrote:
> >>
> >>  On May 28, 2008 at 21:43 [EMAIL PROTECTED] (Peter Beckman) wrote:
>  On Wed, 28 May 2008, Dorn Hetzel wrote:
> 
> > I would think that simply requiring some appropriate amount of
> >>> irrevocable
> > funds (wire transfer, etc) for a deposit that will be forfeited in
> the
> >>> case
> > of usage in violation of AUP/contract/etc would be both sufficient
> and
> >>> not
> > excessive for allowing port 25 access, etc.
>    Until you find out that the source of those supposedly irrevocable
> >>> funds
>    was stolen or fraudulent, and you have some sort of court subpoena
> to
> >>> give
>    it back.
> 
>    I don't believe there is a way for you to outwit the scammer/spammer
> >>> by
>    making them pay more of their or someone elses money.  If you have
> >>> what
>    they need, they'll find a way to trick you into giving it to them.
> >>> Are you still trying to prove that Amazon, Dell, The World, etc can't
> >>> possibly work?
> >>>
> >>  Amazon and Dell ship physical goods.  Amazon Web Services sells
> services,
> >>  as do I.  Services are commonly enabled and activated immediately after
> >>  payment or verification of a valid credit card, as is often expected by
> >>  the customer immediately after payment.  Shipment of physical goods
> will
> >>  almost always take at least 24 hours, often longer, enabling more
> thorough
> >>  checks of credit, however they might do it.
> >>
> >>  And even with the extra time to review the transaction and attempt to
> >>  detect fraud, I'm confident Amazon and Dell lose millions per year due
> to
> >>  fraud.  The reality is that the millions they lose to fraud doesn't
> affect
> >>  us becaus

RE: IOS Rookit: the sky isn't falling (yet)

[Jim Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 29 May 2008, Fred Reimer wrote:

>plaintext (the IOS code) and the hash.  It is not trivial to be able to
>make changes in the code and maintain the same hash value, but there has
>been at least limited success in doing so.

Has there?  My understanding is that constructing a new image to match 
an existing MD5 checksum (vs. constructing two new images with matching 
MD5 checksums) was still not feasible.  Did I miss something?


>It may not be possible to replace the boot ROM, because presumably the new
>hardware would check the ROM code hash before loading it and also
>presumably the ROM code does not have quite as much text messages that can
>be changed to generate the same hash value, thereby bypassing the security
>checks.

This may be an obvious question, but given that the code which verifies an
IOS image would (presumably) be part of the boot ROM, where would you put
the code which verifies the boot ROM?  What does it mean to say `the
hardware' should check the boot ROM?

- -- 
Jim Wise
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIPrGtq/KRbT0KwbwRArN+AJ0QTuytahkUluOYpCHQ9jw94gNWFQCfTQ5c
2V0w8OO3EnCnJvb3lYh1+sQ=
=o9Ro
-END PGP SIGNATURE-

Re: IOS Rookit: the sky isn't falling (yet)

[Steven M. Bellovin]

On Thu, 29 May 2008 09:18:07 -0400
"Fred Reimer" <[EMAIL PROTECTED]> wrote:
 
> So the only easy way to attack this is the MD5 hash.  We have a know
> plaintext (the IOS code) and the hash.  It is not trivial to be able
> to make changes in the code and maintain the same hash value, but
> there has been at least limited success in doing so. 

No there has not.  There has been considerable success at creating
*collisions*; if you don't have a collaborator inside Cisco's build
team, that does you no good in this case.  There has been *no* success
at preimage attacks, which is what we're talking about here.  (Aside:
I'm on record as saying I wouldn't be surprised if preimage attacks
were developed soon by the cryptanalytic community, since people are
paying so much more attention to hash functions now, but that hasn't
happened yet.)

If you do have a collaborator, there is a conceivable attack.  Use the
collision attack -- that is, the ability to simultaneously produce two
files with the same hash -- to generate a genuine IOS image that is
nevertheless susceptible to being replaced by a corrupted one.  It's a
delicate process, though, since even a 1-bit change will completely
change the hash output and ruin the collision.  You're much better off
having your collaborator simply install a back door for you -- and it
almost certainly won't be found.  See
http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or
Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: amazonaws.com?

[Joel Jaeggli]

Dorn Hetzel wrote:
Yeah, there was a day when anyone could buy a pickup truck full of 
ammonium nitrate fertilizer from a random feed store and not attract any 
attention at all, now, maybe not.  Just like port 25, it has plenty of 
legitimate uses, and some more problematic ones.


Equating port 25 use with domestic terrorism is specious.

Ammonium nitrate requires requires some care in handling regardless of 
your intentions,see for exmple the oppau or texas city disasters.


On Thu, May 29, 2008 at 9:14 AM, Matthew Huff <[EMAIL PROTECTED] 
> wrote:


The financial services world felt the same pre-9/11. Since then
FINRA and SEC regulations enforce "Know Your Customer" rules that
require extensive record keeping. The regulations now are quite
burdensome. Given that usage of "cloud" resources could be used for
DDOS and other illegal activities, I wonder how long it will take
companies to realize that if they don't do a good job of self
policing, the result will be something they would prefer not to have
happen.


Matthew Huff   | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
www.otaotr.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139

-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED] ]
Sent: Thursday, May 29, 2008 9:09 AM
To: Dorn Hetzel
Cc: nanog@nanog.org 
Subject: Re: amazonaws.com ?

Dorn Hetzel wrote:
 > There is a really huge difference in the ease with which payment
from a
 > credit card can be reversed if fraudulent, and the amount of effort
 > necessary to reverse a wire transfer. I won't go so far as to say
that
 > reversing a wire transfer is impossible, but I would claim it's
many orders
 > of magnitude harder than the credit card reversal.

To paraphrase one of my colleagues from the user interaction world:

   "The key to offering a compelling service is minimising
   transaction hassles."

I encourage all my competitors to implement inconvenient hard to use
payment methods

 > A mere "court subpoena" wouldn't even be remotely sufficient.
 The person
 > wanting their money back would pretty much have to sue for it and
win.
 > Heck, people that get scammed and send their money via western
union can't
 > even get their money back...  People who sell physical goods that get
 > shipped internationally to places where they can't get them back
from have
 > been dealing with irrevocable payment forms for a long, long
time, and those
 > are generally wire transfers.
 >
 > Once that guy in Frackustan has my widgets, I need to make darn
sure he
 > can't take his money back :)
 >
 > So, yeah, there would be some customers for whom the couple of
business
 > hours it take their wire to go through (that's a pretty typical
time from my
 > actual experience) would be longer than they would want to wait
for their
 > port 25 or other "risky" service to be enabled, but really, how
many is that
 > going to be.  We're not talking about the wait for ordinary
customers who
 > don't need those particular services that tend to be problem
children, and
 > we're not talking about existing accounts of long standing, just
about a
 > barrier for the drive-by customer who wants to use services and
then not pay
 > the cost when they violate the AUP...
 >
 > On Wed, May 28, 2008 at 11:53 PM, Peter Beckman
<[EMAIL PROTECTED] > wrote:
 >
 >> On Wed, 28 May 2008, Barry Shein wrote:
 >>
 >>  On May 28, 2008 at 21:43 [EMAIL PROTECTED]
 (Peter Beckman) wrote:
  On Wed, 28 May 2008, Dorn Hetzel wrote:
 
 > I would think that simply requiring some appropriate amount of
 >>> irrevocable
 > funds (wire transfer, etc) for a deposit that will be
forfeited in the
 >>> case
 > of usage in violation of AUP/contract/etc would be both
sufficient and
 >>> not
 > excessive for allowing port 25 access, etc.
    Until you find out that the source of those supposedly
irrevocable
 >>> funds
    was stolen or fraudulent, and you have some sort of court
subpoena to
 >>> give
    it back.
 
    I don't believe there is a way for you to outwit the
scammer/spammer
 >>> by
    making them pay more of their or someone elses money.  If
you have
 >>> what
    they need, they'll find a way to trick you into giving it to
them.
 >>> Are you still trying to prove that Amazon, Dell, The World, etc
can't
 >>> possibly work?
 >>>
 >>  Amazon 

Re: IOS Rookit: the sky isn't falling (yet)

[Jared Mauch]

On May 29, 2008, at 9:37 AM, Jim Wise wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 29 May 2008, Fred Reimer wrote:

plaintext (the IOS code) and the hash.  It is not trivial to be  
able to
make changes in the code and maintain the same hash value, but  
there has

been at least limited success in doing so.


Has there?  My understanding is that constructing a new image to match
an existing MD5 checksum (vs. constructing two new images with  
matching

MD5 checksums) was still not feasible.  Did I miss something?


	I think the point here is that most (read: average) consumers don't  
verify the md5/sha1/gpg/pgp signatures of the binaries they run.  If  
that was the case, we wouldn't have problems quite as bad as we do  
today.


It may not be possible to replace the boot ROM, because presumably  
the new

hardware would check the ROM code hash before loading it and also
presumably the ROM code does not have quite as much text messages  
that can
be changed to generate the same hash value, thereby bypassing the  
security

checks.


This may be an obvious question, but given that the code which  
verifies an
IOS image would (presumably) be part of the boot ROM, where would  
you put

the code which verifies the boot ROM?  What does it mean to say `the
hardware' should check the boot ROM?


I agree with you here.  Cisco even ships methods to do a field-upgrade  
of the rommon on a variety of platforms and linecards.  There are  
numerous challenges when talking about how to prevent these types of  
updates.  I could imagine a case where you leverage the current  
'phlashing' stuff to "brick" your router rommon so it won't boot.   
Once again it gets to the how do you obtain an exploit path to perform  
these actions on the device?  I always have said physical access =  
"root".  Perhaps the path is that oob modem?  You need to think about  
these things, but unless you have a mission dealing with state secrets  
or your corporate IP (not the protocol) guys treat everything like it  
is (eg: pharmaceutical companies), you're likely to not notice the  
router in the closet has a 2 year old bogon filter list installed.


- Jared

RE: IOS Rookit: the sky isn't falling (yet)

[Fred Reimer]

This is not a crypto form, so we shouldn't get deep into the MD5 collision
debate, but I didn't say HOW there has been limited success.  Sorry if the
wording of my message was not clear and implied that all you would need were
the plaintext and the hash.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697


> -Original Message-
> From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 9:43 AM
> To: Fred Reimer
> Cc: Gadi Evron; nanog@nanog.org
> Subject: Re: IOS Rookit: the sky isn't falling (yet)
> 
> On Thu, 29 May 2008 09:18:07 -0400
> "Fred Reimer" <[EMAIL PROTECTED]> wrote:
> 
> > So the only easy way to attack this is the MD5 hash.  We have a know
> > plaintext (the IOS code) and the hash.  It is not trivial to be able
> > to make changes in the code and maintain the same hash value, but
> > there has been at least limited success in doing so.
> 
> No there has not.  There has been considerable success at creating
> *collisions*; if you don't have a collaborator inside Cisco's build
> team, that does you no good in this case.  There has been *no* success
> at preimage attacks, which is what we're talking about here.  (Aside:
> I'm on record as saying I wouldn't be surprised if preimage attacks
> were developed soon by the cryptanalytic community, since people are
> paying so much more attention to hash functions now, but that hasn't
> happened yet.)
> 
> If you do have a collaborator, there is a conceivable attack.  Use the
> collision attack -- that is, the ability to simultaneously produce two
> files with the same hash -- to generate a genuine IOS image that is
> nevertheless susceptible to being replaced by a corrupted one.  It's a
> delicate process, though, since even a 1-bit change will completely
> change the hash output and ruin the collision.  You're much better off
> having your collaborator simply install a back door for you -- and it
> almost certainly won't be found.  See
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or
> Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf
> 
> 
>   --Steve Bellovin, http://www.cs.columbia.edu/~smb


smime.p7s
Description: S/MIME cryptographic signature

RE: IOS Rookit: the sky isn't falling (yet)

[Fred Reimer]

The code would presumably be run upon boot from a non-flashable source,
which would run the boot ROM code through a check on the crypto chip and
only execute it if it passed.  You would not put the code that checks the
boot ROM on the boot ROM.  The new crypto chip would presumably have the
initial boot code, which would only be designed to check the boot ROM
signature and nothing else so presumably would never need to be replaced and
hence would be designed to be non-flashable.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697


> -Original Message-
> From: Jared Mauch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 9:48 AM
> To: Jim Wise
> Cc: Fred Reimer; nanog@nanog.org
> Subject: Re: IOS Rookit: the sky isn't falling (yet)
> 
> 
> On May 29, 2008, at 9:37 AM, Jim Wise wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Thu, 29 May 2008, Fred Reimer wrote:
> >
> >> plaintext (the IOS code) and the hash.  It is not trivial to be
> >> able to
> >> make changes in the code and maintain the same hash value, but
> >> there has
> >> been at least limited success in doing so.
> >
> > Has there?  My understanding is that constructing a new image to
> match
> > an existing MD5 checksum (vs. constructing two new images with
> > matching
> > MD5 checksums) was still not feasible.  Did I miss something?
> 
>   I think the point here is that most (read: average) consumers
> don't
> verify the md5/sha1/gpg/pgp signatures of the binaries they run.  If
> that was the case, we wouldn't have problems quite as bad as we do
> today.
> 
> >> It may not be possible to replace the boot ROM, because presumably
> >> the new
> >> hardware would check the ROM code hash before loading it and also
> >> presumably the ROM code does not have quite as much text messages
> >> that can
> >> be changed to generate the same hash value, thereby bypassing the
> >> security
> >> checks.
> >
> > This may be an obvious question, but given that the code which
> > verifies an
> > IOS image would (presumably) be part of the boot ROM, where would
> > you put
> > the code which verifies the boot ROM?  What does it mean to say `the
> > hardware' should check the boot ROM?
> 
> I agree with you here.  Cisco even ships methods to do a field-upgrade
> of the rommon on a variety of platforms and linecards.  There are
> numerous challenges when talking about how to prevent these types of
> updates.  I could imagine a case where you leverage the current
> 'phlashing' stuff to "brick" your router rommon so it won't boot.
> Once again it gets to the how do you obtain an exploit path to perform
> these actions on the device?  I always have said physical access =
> "root".  Perhaps the path is that oob modem?  You need to think about
> these things, but unless you have a mission dealing with state secrets
> or your corporate IP (not the protocol) guys treat everything like it
> is (eg: pharmaceutical companies), you're likely to not notice the
> router in the closet has a 2 year old bogon filter list installed.
> 
>   - Jared



smime.p7s
Description: S/MIME cryptographic signature

RE: IOS Rookit: the sky isn't falling (yet)

[Jim Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 29 May 2008, Fred Reimer wrote:

>The code would presumably be run upon boot from a non-flashable source,
>which would run the boot ROM code through a check on the crypto chip and
>only execute it if it passed.  You would not put the code that checks the
>boot ROM on the boot ROM.  The new crypto chip would presumably have the
>initial boot code, which would only be designed to check the boot ROM
>signature and nothing else so presumably would never need to be replaced and
>hence would be designed to be non-flashable.

Doesn't this just push the chicken-and-egg problem up the chain one step?
The ROMMON would be flashable (among other reasons) because the key used to
sign IOS releases should change over the years -- gaining length as cycles
get cheaper, being replaced periodically to prevent use of the same key for
too long, and perhaps being revoked if it should ever be compromised.

If the ROMMON is itself to be verified by a prior, non-flashable ROM, then
all the same arguments would call for making its key-list updatable -- and
given the time-in-service seen by many such devices, any weakness in that
key list would be around for quite some time.

- -- 
Jim Wise
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw
43+1Pq3xWS4MagWzdetZ0ws=
=62gJ
-END PGP SIGNATURE-

RE: IOS Rookit: the sky isn't falling (yet)

[Fred Reimer]

New keys, to be stored on the crypto chip, would presumably be delivered in
a separately signed package using a master key that would not change
(embedded within the chip).  Maybe Cisco even doesn't have this key, and
would need to send a revocation or new public key to be stored on the chip
to the chip manufacturer, who would sign it with the master private key and
which then could be delivered in a software update to the system.  There are
many possibilities, and no crypto scheme is foolproof.  That much has been
proven.  But no, you would not make the on-chip EEPROM of the crypto chip
"flashable" in the normal meaning of the word.  You would send the chip a
pointer to a buffer that contains a signed update key, and the chip itself
would verify that signature and only then program the updated key(s).

My intention was not to turn nanog into a crypto forum.  I'd be much more
interested in any unique methods that people use to harden their systems
that have not already been widely distributed through vendor or industry
best practices.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697


> -Original Message-
> From: Jim Wise [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2008 11:10 AM
> To: Fred Reimer
> Cc: Jared Mauch; nanog@nanog.org
> Subject: RE: IOS Rookit: the sky isn't falling (yet)
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Thu, 29 May 2008, Fred Reimer wrote:
> 
> >The code would presumably be run upon boot from a non-flashable
> source,
> >which would run the boot ROM code through a check on the crypto chip
> and
> >only execute it if it passed.  You would not put the code that checks
> the
> >boot ROM on the boot ROM.  The new crypto chip would presumably have
> the
> >initial boot code, which would only be designed to check the boot ROM
> >signature and nothing else so presumably would never need to be
> replaced and
> >hence would be designed to be non-flashable.
> 
> Doesn't this just push the chicken-and-egg problem up the chain one
> step?
> The ROMMON would be flashable (among other reasons) because the key
> used to
> sign IOS releases should change over the years -- gaining length as
> cycles
> get cheaper, being replaced periodically to prevent use of the same key
> for
> too long, and perhaps being revoked if it should ever be compromised.
> 
> If the ROMMON is itself to be verified by a prior, non-flashable ROM,
> then
> all the same arguments would call for making its key-list updatable --
> and
> given the time-in-service seen by many such devices, any weakness in
> that
> key list would be around for quite some time.
> 
> - --
>   Jim Wise
>   [EMAIL PROTECTED]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (NetBSD)
> 
> iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw
> 43+1Pq3xWS4MagWzdetZ0ws=
> =62gJ
> -END PGP SIGNATURE-


smime.p7s
Description: S/MIME cryptographic signature

Re: amazonaws.com?

[Barry Shein]

On May 28, 2008 at 23:53 [EMAIL PROTECTED] (Peter Beckman) wrote:
 > 
 >   Getting someone to fax their ID in takes extra time and resources, and
 >   means it might be hours before you get your account "approved," and for
 >   some service providers, part of the value of the service is the immediacy
 >   in which a customer can gain new service.

Right, which means they're monetizing the risk and cost of damages for
the rest of the net. They're selling your resources also (e.g., need
for firewalls, bandwidth, cleanup.) That monetization needs to be
recognized.

If I rented cars to people w/o checking creds to a reasonable standard
and those cars were used in the commission of crimes or generated a
lot of insurance claims and emergency personnel expenses what would
the reaction be? I doubt it would be "...but fast turnaround is that
car rental company's competitive advantage! what can they do???"

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: amazonaws.com?

[Peter Beckman]

On Thu, 29 May 2008, Dorn Hetzel wrote:


There is a really huge difference in the ease with which payment from a
credit card can be reversed if fraudulent, and the amount of effort
necessary to reverse a wire transfer. A mere "court subpoena" wouldn't
even be remotely sufficient. The person wanting their money back would
pretty much have to sue for it and win.

So, yeah, there would be some customers for whom the couple of business
hours it take their wire to go through would be longer than they would
want to wait for their port 25 or other "risky" service to be enabled,
but really, how many is that going to be.


 In the end, all you've done with these "extra" AUP and risk charges is
 line YOUR (generally, not directed at you Dorn) pockets while the rest of
 us suffer under the deluge of spam sent from your systems.  Which still
 sucks for the rest of the 'net.

 I suspect that for Amazon, it is easier and cheaper for them to screw us
 and allow spam to flow out port 25 unhindered (which costs US money and
 time) than it is to implement something that makes them a good Internet
 citizen (which costs AMAZON money and time).  Maybe they'll change their
 stance, but I suspect it is a business decision to not block port 25 and
 hang out on blacklists, not a good Internet citizen decision.

 My position from the beginning of this thread is that you cannot AUP this
 problem away, nor can you just "charge more" and hope THAT will stop it,
 nor can you simply improve and perfect anti-fraud systems so spammers and
 fraudsters cannot gain access to your services.

 It's free to do nothing, and there is a cost of doing something.  There
 are no laws that say what Amazon is doing is illegal, either.  You have
 choices: null route them, blacklist them, get a group together (NANOG?)
 and group null route Amazon's EC2 IP blocks until they bow to your
 demands.  Being on the 'net means spam, DOS attacks, being slashdotted,
 dealing with bad Internet citizens, etc.  Either you accept those facts,
 or you should give up and go unplug your connection.

 With a backhoe, preferably.  Much more fun.

Beckman
---
Peter Beckman  Internet Guy
[EMAIL PROTECTED] http://www.angryox.com/
---

Re: amazonaws.com?

[Barry Shein]

On May 29, 2008 at 09:07 [EMAIL PROTECTED] (Al Iverson) wrote:
 > On Wed, May 28, 2008 at 11:08 PM, Barry Shein <[EMAIL PROTECTED]> wrote:
 > 
 > > I am a big, big fan of assessing charges for AUP abuse and making some
 > > realistic attempt to try to make sure it's collectible, and otherwise
 > > make some attempt to know who you're doing business with.
 > 
 > Just out of curiosity, what stats can you make available as far as:
 > - How often you assess this AUP abuse fee?
 > - How often it is successfully collected?
 > - How successful are chargebacks against that fee?

I'll just say we have certainly assessed AUP abuse fees and in most
cases collected those fees.

The most common fee is a $50 per incident charge for spam complaints
after a stern warning or two which depends on frequency, a few per day
is very different than one or two per month, and what to do with those
phony AOL TOS complaints which almost always mean "I asked to be on
this list but I forgot how to get off so maybe if I keep clicking the
spam button..."?

These are not generally for all-out spamming in our experience. I
don't think that's even happened from here in this century. But I've
had people who sold services and harvested addresses from, e.g.,
usenet groups or mailing lists they joined specific to those services
(kinda like the router salesman you sometimes hear about on nanog)
which generated complaints. They got a lecture and a warning. In a few
cases their persistance got them billed, as warned, which usually put
a stop to it.

One time very early on I remember someone did some more egregious
spamming and I shut him down and added a $1500 clean-up fee and he
paid it. I was a bit shocked. I've billed a few others like that and
of course they just disappeared.

One advantage of AUP abuse fees, from a business point of view, is
that if you've done your homework (in the AUP, customer clearly warned
on first offense, response received) you can then shut them down
pending a significant deposit or payment of abuse fees on your terms.
You can, e.g., say this is too much for a credit card if you doubt
their trustworthiness, credit cards aren't legal tender, and demand
some more trustworthy payment method.

Let's be frank, once you're pretty sure they're willful spammers
you're not losing a lot of sleep over keeping them happy, you're
mostly trying to get rid of them unless this is really something
they're willing to give up entirely.

Should they try to come back at you legally this is a lot more
understandable ("I never extended them a credit relationship of $1500
on a $20/mo account!") than just "we didn't like what they were doing
with their account". Anyone can understand non-payment, even a court,
so claims of "business damages" etc mostly go out the window ("but if
it was so important to your business why didn't you just pay the
fees??? it was in their AUP, didn't you read it?")

Obviously the fees have to be steep enough to discourage even someone
who might otherwise be willing to pay the fees. And for the way
spammers work that doesn't have to be very high, they mostly shoot for
"free" as an overhead goal, even the semi-legitimate types who would
claim they're just doing direct email marketing and sell products a
little more credible than herbal body enlargement pills.

At any rate I'll admit all this begs the zombie bot spammers and
others whose businesses are entirely built on crime and fraud but we
were talking about computing clouds.

As to chargebacks, over almost 20 years we've punched millions of card
charges and I'd say the number of chargebacks is small enough that it
usually gets mentioned when it happens, "hmm, we had a couple of
chargebacks this month", very few, certainly not one a month.

We have what I'd call a normal number of "card invalid" (closed, over
limit, expiration date wrong, etc.), you get a steady stream of those,
but nothing I'd call serious and in most cases gets straightened out
with the customer...before someone (as usually happens in these
discussions) re-defines those as "chargebacks" and uses the
redefinition to question my credibility/sanity. By chargebacks I mean
a disputed charge, they're clearly distinguished in your merchant acct
from just "bad" cards.

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: amazonaws.com?

[Barry Shein]

On May 29, 2008 at 06:08 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > 
 > To paraphrase one of my colleagues from the user interaction world:
 > 
 >  "The key to offering a compelling service is minimising
 >  transaction hassles."
 > 
 > I encourage all my competitors to implement inconvenient hard to use 
 > payment methods

One way of describing it is "minimizing transaction hassles".

Another way of describing it is "monetizing others' hassles", let them
spend on bandwidth, firewalls, personnel, etc, to deal with my
customers' spamming.

That's the arbitrage we're currently deaing with.

But you're right, there was no good reason for tobacco companies to
concern themselves with the cost of health effects of their products
for many, many years, it wasn't their problem.

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: amazonaws.com?

[Barry Shein]

On May 29, 2008 at 06:46 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > Dorn Hetzel wrote:
 > > Yeah, there was a day when anyone could buy a pickup truck full of 
 > > ammonium nitrate fertilizer from a random feed store and not attract any 
 > > attention at all, now, maybe not.  Just like port 25, it has plenty of 
 > > legitimate uses, and some more problematic ones.
 > 
 > Equating port 25 use with domestic terrorism is specious.
 > 
 > Ammonium nitrate requires requires some care in handling regardless of 
 > your intentions,see for exmple the oppau or texas city disasters.

And how different is that from the million+ strong zombie botnets? Who
owns (not pwns) those zombie'd systems and what were their intentions?

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: amazonaws.com?

[Luke S Crawford]

Peter Beckman <[EMAIL PROTECTED]> writes:

>   If you are taking card-not-present credit card transactions over the
...snip "hard to charge fradulent customers" and also "verifying customer
identity annoys the customer"... points-  


The goal here is to give abuse a negative expected return.
One way to do this is to charge (and collect)  a fee that is greater than 
what the spammer can earn between when they sign up and when you shut then 
down.  There are two ways to do this -  1. raise (and collect) the abuse fee, 
or 2. lower the amount they can earn before you shut them down.  

I am suggesting that we put some effort into 2- If we can reduce the 
amount of time between when a spammer signs up and when they are shut
down, we raise the spammer's costs.  I think there is low-hanging fruit
in this area.  

I believe that the 'strongly authenticate customer, then take legal 
action' model is dictated by the fact that most abuse incidents are not
actually reported to your abuse desk- some abusive customers can go days
or weeks before you receive a complaint.  to give abuse a negative expected
return, then, you need to make the consequence expensive.  (to say nothing
of covering the costs of trying to get good logs/evidence out of those who
are complaining, or trying to figure out if your customer is a spammer
or if your customer was owned by a spammer, and the costs of collecting the
fee.)

I wanted to point out another option providers now have.  IDS technology
has matured.  Snort is free and pretty standard.   Personally, I find 
monitoring incoming traffic to be... of limited utility.  However, 
I believe snort is an excellent tool for lowering the cost of running an 
abuse desk, if you run it on the outgoing traffic. Snort is pretty good 
about alerting you to outgoing abuse before people complain.  Heck, if you 
trust it, you can have it automatically shut down the abusive customers.

Re: amazonaws.com?

[Joel Jaeggli]

Barry Shein wrote:

On May 29, 2008 at 06:46 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > Dorn Hetzel wrote:
 > > Yeah, there was a day when anyone could buy a pickup truck full of 
 > > ammonium nitrate fertilizer from a random feed store and not attract any 
 > > attention at all, now, maybe not.  Just like port 25, it has plenty of 
 > > legitimate uses, and some more problematic ones.
 > 
 > Equating port 25 use with domestic terrorism is specious.
 > 
 > Ammonium nitrate requires requires some care in handling regardless of 
 > your intentions,see for exmple the oppau or texas city disasters.


And how different is that from the million+ strong zombie botnets? Who
owns (not pwns) those zombie'd systems and what were their intentions?


Well let's see. The texas city disaster is/was considered the worst 
industrial accident in american history. 581 people killed by an 
explosive yield of about 2 kilotons. The secondary effects includes 
fires in many of the chemical facilities in Galveston and a swath of 
destruction that reached up to 40 miles inland...


http://www.local1259iaff.org/disaster.html

So no, I don't think internet attached hosts can casually equated with 
the destructive potential of a pile of fertilizer at least not in the 
context described.

Re: amazonaws.com?

[Peter Beckman]

On Thu, 29 May 2008, Luke S Crawford wrote:


Peter Beckman <[EMAIL PROTECTED]> writes:


  If you are taking card-not-present credit card transactions over the

...snip "hard to charge fradulent customers" and also "verifying customer
identity annoys the customer"... points-

The goal here is to give abuse a negative expected return.  One way to do
this is to charge (and collect)  a fee that is greater than what the
spammer can earn between when they sign up and when you shut then down.
There are two ways to do this -  1. raise (and collect) the abuse fee, or
2. lower the amount they can earn before you shut them down.


 All these charges do is line the coffers.  Sure, a few might be prevented
 from doing it in the first place, but the rest will continue, and everyone
 else here, including Barry, will continue to get hit by spam and DOS and
 backscatter.


I wanted to point out another option providers now have.  IDS technology
has matured.  Snort is free and pretty standard.   Personally, I find
monitoring incoming traffic to be... of limited utility.  However,
I believe snort is an excellent tool for lowering the cost of running an
abuse desk, if you run it on the outgoing traffic. Snort is pretty good
about alerting you to outgoing abuse before people complain.  Heck, if you
trust it, you can have it automatically shut down the abusive customers.


 This is what I think we should ALL be doing -- monitoring our own network
 to make sure we aren't the source, via customers, of the spam or DOS
 attacks.  All outbound email from your own network should be scanned by
 some sort of best-practice system before delivery to prevent or limit spam
 from originating on your network.  IMO.

 But let's be realistic -- the reality is that not everyone does, due to
 financial or resource or management constraints, and that receiving spam
 and being hit by DOS attacks and being slashdotted is simply part of the
 cost of being on the 'net.

 Profiting MORE from those that proliferate these attacks may hurt you less
 in the bottom line, but it still hurts everyone else who is the target of
 the attacks enabled by high AUP abuse fees.

 I know I'd be just as ticked off about a spam attack from Amazon EC2,
 whether or not Amazon got paid extra to enable it.

Beckman
---
Peter Beckman  Internet Guy
[EMAIL PROTECTED] http://www.angryox.com/
---

Re: amazonaws.com?

[Barry Shein]

What I really, really, (really), don't understand is what is this
perverse urge to argue incessantly that spam and related do little or
no harm, are of little consequence, and nothing can be done about it
anyhow? You'd think we were discussing ways to prevent hurricanes (and
some won't even accept that there's no answer to those!)

I realize there's a little bit of one-upsmanship to just beating a
hopeless point to death (ok, fine, huge ammonium nitrate explosions
which level entire cities are worse than million+ zombie bot armies,
and superman can beat up the hulk, etc.)

Zombie bot armies et al do cause probably billions of dollars in
damages (e.g., equipment and personnel to deal with them not to
mention lost productivity by end users), undermine trust, etc.

But don't you ever stop to consider where your collective bread is
buttered before you give the public and quotable impression as
professionals that whether or not spam, phishing et al are bad is
debateable, like we were arguing creationism vs. evolution, that
there's no point in even trying to curb it, that credit cards can't
possibly work, etc?

It's one thing to give an idea a proper vetting, it's something else
to work backwards from the assumption that nothing can possibly be
done and just use reasoning like "I can think of something even worse,
so therefore it's not so bad", or "fraud has occurred in credit card
transactions, therefore credit cards cannot be viable."

On May 29, 2008 at 11:10 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > Barry Shein wrote:
 > > On May 29, 2008 at 06:46 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > >  > Dorn Hetzel wrote:
 > >  > > Yeah, there was a day when anyone could buy a pickup truck full of 
 > >  > > ammonium nitrate fertilizer from a random feed store and not attract 
 > > any 
 > >  > > attention at all, now, maybe not.  Just like port 25, it has plenty 
 > > of 
 > >  > > legitimate uses, and some more problematic ones.
 > >  > 
 > >  > Equating port 25 use with domestic terrorism is specious.
 > >  > 
 > >  > Ammonium nitrate requires requires some care in handling regardless of 
 > >  > your intentions,see for exmple the oppau or texas city disasters.
 > > 
 > > And how different is that from the million+ strong zombie botnets? Who
 > > owns (not pwns) those zombie'd systems and what were their intentions?
 > 
 > Well let's see. The texas city disaster is/was considered the worst 
 > industrial accident in american history. 581 people killed by an 
 > explosive yield of about 2 kilotons. The secondary effects includes 
 > fires in many of the chemical facilities in Galveston and a swath of 
 > destruction that reached up to 40 miles inland...
 > 
 > http://www.local1259iaff.org/disaster.html
 > 
 > So no, I don't think internet attached hosts can casually equated with 
 > the destructive potential of a pile of fertilizer at least not in the 
 > context described.
 > 

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

APNIC receives 112 /8 and 113 /8

[Leslie Nobile]

Forwarding this email on behalf of APNIC...



New IPv4 allocation for APNIC (112/8 and 113/8) 


Dear colleagues

The information in this announcement is to enable the Internet community to 
update network configurations, such as routing filters, where required.

APNIC received the following IPv4 address blocks from IANA in May
2008 and will be making allocations from these ranges in the near
future:

112/8
113/8

Reachability and routability testing of the new prefixes will commence soon. 
The daily report will be published at the usual URL:

http://www.ris.ripe.net/debogon

For more information on the resources administered by APNIC, please see:

http://www.apnic.net/db/ranges.html

For information on the minimum allocation sizes within address ranges 
administered by APNIC, please see:

http://www.apnic.net/db/min-alloc.html


Kind regards,



APNIC Secretariat
Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100
PO Box 2131 Milton, QLD 4064 Australia  Fax: +61-7-3858-3199
Level 1, 33 Park Road, Milton, QLD  http://www.apnic.net

Update was Re: [NANOG] Level3 not honoring Broadwing contracts?

[up]

Update to below (sorry for top-post, but not everone needs to read the 
original post).


Thanks in part to the pro-bono efforts of two very good attorneys: Nachman 
Yaakov Ziskind, ([EMAIL PROTECTED]) (nanog list member who kindly 
emailed me when I sent this to the list) and my father in law, Level 3 has 
acknowledged that my contract is still in term and will honor their 
contract until it expires in August of 2009.


The contract has a provision for paying only the undisputed portion of 
disputed invoices, provided formal notice is given, so I followed it and 
CC'd the director of colo services who sent me the original letter of 
intent to raise my pricing, along with Mr. Ziskind's letter and it got 
taken care of.


Thank you to everyone who responded to this last month.  If anybody else 
is having similar issues and would like more information, please don't 
hesitate to contact me off-list.


On Mon, 28 Apr 2008, [EMAIL PROTECTED] wrote:



In 2006, I signed a 3 year contract with Broadwing for a 1 cabinet
colocation with 6Mbs dedicated for under $1,000/mo.  A few weeks ago,
about halfway through this contract, I get a letter from Level 3's
"Director of Colocation" that they are going to raise my price by several
hundred dollars a month.

I spoke with my new Level 3 rep, and he just notified me that their legal
deparment confirms that all they have to do is give me 30 days notice to
increase their price.

This does not make sense to me.  I am bound to a 3 year contract, where I
have to pay them the rest of the term if I were to leave early, but they
can jack up the price by 40-50% during that time, arbitrarily?  I do not
see that provision in my contract, and would rather avoid legal expenses
if possible.  Has anyone else had to deal with this sort of thing from
Level 3?

TIA,

James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]   
http://3.am
=

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog



James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]   
http://3.am
=

Re: Hurricane season starts June 1: Carriers harden networks

[Roland Perry]

In article 
<[EMAIL PROTECTED]

.net>, [EMAIL PROTECTED] writes

The official spokespeople don't mention it, but there is also
a tendency for local officials to divert fuel delivery trucks
for their use instead of maintaining communication facilities.


How much fuel can you legally carry in drums inside the trucks that
your company already has with your logo on it? Is it logistically
feasible to resupply your sites using such vehicles?


Briefly, you also need permission for those trucks to be moving inside 
the cordons. What you need to know who to ask to get that permission, 
and why they should believe your business case.

--
Roland Perry

Re: amazonaws.com?

[Luke S Crawford]

Peter Beckman <[EMAIL PROTECTED]> writes:
...snip "use snort" suggestion

>   This is what I think we should ALL be doing -- monitoring our own network
>   to make sure we aren't the source, via customers, of the spam or DOS
>   attacks.  All outbound email from your own network should be scanned by
>   some sort of best-practice system before delivery to prevent or limit spam
>   from originating on your network.  IMO.
>   But let's be realistic -- the reality is that not everyone does, due to
>   financial or resource or management constraints

I believe that in the case of a VPS provider like ec2,  monitoring outgoing
traffic with an IDS is cheaper than not monitoring it. 

Abuse reports are expensive to process.  You need people with both
social and technical skills on your end, people with social and technical
skills who are willing to do what amounts to technical support.  Often the 
abuse reports are vague, requiring back-and-fourth.  Even if your IDS only 
catches a small percentage  of the abuse-generating complaints (and I bet 
the IDS can get a large percentage of the complaint-generating abuse-
it takes a lot of abuse to generate a complaint)  you are saving
a lot of money on abuse desk services.  Heck, I bet just the ability
to search IDS logs after a abuse report would pay for the IDS.

Re: amazonaws.com?

[Joel Jaeggli]

Barry Shein wrote:

What I really, really, (really), don't understand is what is this
perverse urge to argue incessantly that spam and related do little or
no harm, are of little consequence, and nothing can be done about it
anyhow? You'd think we were discussing ways to prevent hurricanes (and
some won't even accept that there's no answer to those!)

I realize there's a little bit of one-upsmanship to just beating a
hopeless point to death (ok, fine, huge ammonium nitrate explosions
which level entire cities are worse than million+ zombie bot armies,
and superman can beat up the hulk, etc.)


So don't use bad analogies... Describe the scope of the possible harm 
you envision.



Zombie bot armies et al do cause probably billions of dollars in
damages (e.g., equipment and personnel to deal with them not to
mention lost productivity by end users), undermine trust, etc.

But don't you ever stop to consider where your collective bread is
buttered before you give the public and quotable impression as
professionals that whether or not spam, phishing et al are bad is
debateable, like we were arguing creationism vs. evolution, that
there's no point in even trying to curb it, that credit cards can't
possibly work, etc?


The fact that is criminal enterprise is undesirable is not a subject of 
much debate.


I object to the notion the destruction of life and property are suitably 
analogous to spam, fraud, theft of resource and denial of service. They 
aren't. One is at risk of minimizing the suffering of the victims of the 
former by equating them with the later.



It's one thing to give an idea a proper vetting, it's something else
to work backwards from the assumption that nothing can possibly be
done and just use reasoning like "I can think of something even worse,
so therefore it's not so bad", or "fraud has occurred in credit card
transactions, therefore credit cards cannot be viable."


I don't think there's any evidence of me assuming that. The potential 
for abuse is not a prima facie reason not to do something. Large 
successful parts of our economy as well as the basic human condition are 
devoted to the business of managing opportunity vs risk and the 
mitigation of the later where possible.



On May 29, 2008 at 11:10 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > Barry Shein wrote:
 > > On May 29, 2008 at 06:46 [EMAIL PROTECTED] (Joel Jaeggli) wrote:
 > >  > Dorn Hetzel wrote:
 > >  > > Yeah, there was a day when anyone could buy a pickup truck full of 
 > >  > > ammonium nitrate fertilizer from a random feed store and not attract any 
 > >  > > attention at all, now, maybe not.  Just like port 25, it has plenty of 
 > >  > > legitimate uses, and some more problematic ones.
 > >  > 
 > >  > Equating port 25 use with domestic terrorism is specious.
 > >  > 
 > >  > Ammonium nitrate requires requires some care in handling regardless of 
 > >  > your intentions,see for exmple the oppau or texas city disasters.
 > > 
 > > And how different is that from the million+ strong zombie botnets? Who

 > > owns (not pwns) those zombie'd systems and what were their intentions?
 > 
 > Well let's see. The texas city disaster is/was considered the worst 
 > industrial accident in american history. 581 people killed by an 
 > explosive yield of about 2 kilotons. The secondary effects includes 
 > fires in many of the chemical facilities in Galveston and a swath of 
 > destruction that reached up to 40 miles inland...
 > 
 > http://www.local1259iaff.org/disaster.html
 > 
 > So no, I don't think internet attached hosts can casually equated with 
 > the destructive potential of a pile of fertilizer at least not in the 
 > context described.
 > 

[NANOG-announce] NANOG43 Reminder

[Betty J. Burke]

Dear NANOG Community--

We are looking forward to seeing those who plan to attend NANOG43 at the 
New York Marriott at the Brooklyn Bridge in Brooklyn on Sunday.

We expect excellent attendance, with almost 400 registered attendees to 
date.

Some important highlights for those still considering attending and a 
reminder that registration is required to attend any of the NANOG events.

Registration Fees
-
Through 5-30-08 Registration Fee is @$525
Late and On-Site Registration Fee is @$600


Agenda
--
The agenda is complete and available at:

  http://www.nanog.org/mtg-0806/agenda.html

Community meeting
-
An important part of every NANOG meeting!! NANOG43 Community Meeting is 
scheduled for 5:30-6:30 p.m. on Sunday.


Social gatherings
-
Monday, June 2, 6:00 PM – 8:00 PM
Tuesday, June 3, 6:00 p.m. – 9:00 p.m.
Wednesday, June 4, 7:00 p.m. – 11:00 p.m.

As always, feel free to email [EMAIL PROTECTED] with any questions.


--Merit Network - NANOG Registration & Support


___
NANOG-announce mailing list
[EMAIL PROTECTED]
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: New ID: Special Use IPv4 Addresses

[Jonathan Heinlein]

Link change?

http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-02.txt

On Wed, May 28, 2008 at 3:12 PM, Sean Donelan <[EMAIL PROTECTED]> wrote:

>
> http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-01.txt
>
> Other than a formatting error in the header ("IPv4 Multicast Guidelines")
> instead of ("Special Use IPv4 Addresses"), the only significant change
> appears to be removing the "Reserved" status of the old Classfull boundary
> networks.  The former boundary networks are now subject to allocation like
> any other unicast IPv4 address space.
>
> Host, Router vendors and Network Operators should have already been testing
> their equipment for proper handling (i.e. not doing anything different) of
> these network addresses.  So this ID should just be a minor IANA
> administrative cleanup.
>
>
>

Comcast Users, Time to Change Your Password

[Crist Clark]

I'm getting "connection refused" from Comcast's POP3
servers, mail.comcast.net. Related to this?

http://www.theregister.co.uk/2008/05/29/comcast_domain_hijacked/

Oh, NetSol... Comcast Let the finger pointing begin.
-- 

Crist J. Clark  
[EMAIL PROTECTED]
Globalstar Communications(408)
933-4387


B¼information contained in this e-mail message is confidential, intended
only for the use of the individual or entity named above. If the reader
of this e-mail is not the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that any review, dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this e-mail
in error, please contact [EMAIL PROTECTED] 

Re: New ID: Special Use IPv4 Addresses

[Sean Donelan]

The header was corrected an hour or so after my original message, and
a revised internet-draft (02) was published.



On Thu, 29 May 2008, Jonathan Heinlein wrote:

Link change?

http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-02.txt

On Wed, May 28, 2008 at 3:12 PM, Sean Donelan <[EMAIL PROTECTED]> wrote:



http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-01.txt

Other than a formatting error in the header ("IPv4 Multicast Guidelines")
instead of ("Special Use IPv4 Addresses"), the only significant change
appears to be removing the "Reserved" status of the old Classfull boundary
networks.  The former boundary networks are now subject to allocation like
any other unicast IPv4 address space.

Host, Router vendors and Network Operators should have already been testing
their equipment for proper handling (i.e. not doing anything different) of
these network addresses.  So this ID should just be a minor IANA
administrative cleanup.

Re: Hurricane season starts June 1: Carriers harden networks

[Ian Mason]

On 27 May 2008, at 22:18, Sean Donelan wrote:



The official spokespeople don't mention it, but there is also a  
tendency for local officials to divert fuel delivery trucks for  
their use instead

of maintaining communication facilities.




Some years ago we managed to get the UK government emergency planning  
folks to actually factor this into their plans so that communications  
fuel supplies get adequate priority. In fact we even planned for some  
highly unlikely contingencies. Fortunately we haven't yet had a  
chance to find out if this planning actually works out in practice.


Ian

Re: amazonaws.com?

[Ian Mason]

On 27 May 2008, at 16:33, Robert Bonomi wrote:


From [EMAIL PROTECTED]  Mon May 26 21:16:58 2008
Date: Tue, 27 May 2008 07:46:26 +0530
From: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>
To: "Colin Alston" <[EMAIL PROTECTED]>
Subject: Re: amazonaws.com?
Cc: [EMAIL PROTECTED]

On Tue, May 27, 2008 at 1:10 AM, Colin Alston  
<[EMAIL PROTECTED]> wrote:

On 26/05/2008 18:13 Suresh Ramasubramanian wrote:




I didnt actually, Bonomi did .. but going on ..


Mis-credit where mis-credit isn't due ...  Twasn't me, either.  

I just commented that I couldn't think of a reason for a _compute_  
cluster to
need access to unlimited remote machines/ports.  And that it could  
'trivially'
be made an _automatic_ part of the 'compute session' config -- to  
allow access

to a laundry-list of ports/machines, and those ports/machines -only-.

If Amazon were a 'good neighbor', they _would_ implement something  
like this.
That they see no need to do _anything_ -- when _actual_ problems,  
which are
directly attributable to their failure to do so, have been brought  
to their
attention -- does argue in favor of wholesale firewalling of the  
EC2 address-

space.

If the address-space owner won't police it's own property, there is  
no reason
for the rest of the world to spend the time/effort to _selectively_  
police it

for them.

Amazon _might_ 'get a clue' if enough providers walled off the EC2  
space, and
they found difficulty selling cycles to people who couldn't access  
the machines

to set up their compute applications.


This is a classic example of externalities in the economics of security.

Currently, any damage caused by Amazon customers costs Amazon little  
or nothing. The
costs are borne by the victims of that damage. On the other hand  
mitigating this
damage would cause Amazon costs, in engineering and lost revenue. So  
in economic

terms they have no incentive to 'do the right thing'.

So to get Amazon to police their customers either requires regulation  
or an external
economic pressure. Blocking AWS from folk's mail servers would apply  
some pressure,
making areas of the net go dark to AWS would apply more pressure  
faster. A considerable
amount of pressure could be placed by a big enough money damages  
lawsuit but that has

a feedback delay of months to years.

Re: amazonaws.com?

[Paul Vixie]

[EMAIL PROTECTED] (Ian Mason) writes:

> On 27 May 2008, at 16:33, Robert Bonomi wrote:
> 
> > Amazon _might_ 'get a clue' if enough providers walled off the EC2
> > space, and they found difficulty selling cycles to people who couldn't
> > access the machines to set up their compute applications.
> 
> This is a classic example of externalities in the economics of security.
> 
> Currently, any damage caused by Amazon customers costs Amazon little or
> nothing. The costs are borne by the victims of that damage. On the other
> hand mitigating this damage would cause Amazon costs, in engineering and
> lost revenue. So in economic terms they have no incentive to 'do the
> right thing'.

i've heard this called "the chemical polluter business model".

> So to get Amazon to police their customers either requires regulation or
> an external economic pressure. Blocking AWS from folk's mail servers
> would apply some pressure, making areas of the net go dark to AWS would
> apply more pressure faster. A considerable amount of pressure could be
> placed by a big enough money damages lawsuit but that has a feedback
> delay of months to years.

to that end, i don't accept e-mail from any free e-mail provider, including
gmail, nor from most ISP mail servers.  all of them face this same
economics decision, and all of them end up spewing quite a bit of spam, and
there's no end in sight.  e-mail sourcing doesn't scale.  the highest
quality e-mail comes from the smallest communities.  EC2 will probably face
some boycotts.  i don't think these will change the endgame, whatever it is.
-- 
Paul Vixie

Re: L3/RR "incident" (Previously Network meltdowns anywhere in US?)

[Tuc at T-B-O-H.NET]

Hi,

Another case of getting much better help via NANOG than through a NOC.

Turns out there was an issue, and it subsequently was fixed in a
relatively small timeframe. Atleast a /20 of RR was not visible inside of L3,
I'm not sure if it was more. 

Thanks again to those people from L3 that DID help me who are on this
list.

Tuc/TBOH

Re: amazonaws.com?

[Suresh Ramasubramanian]

On Thu, May 29, 2008 at 10:03 PM, Barry Shein <[EMAIL PROTECTED]> wrote:
> The most common fee is a $50 per incident charge for spam complaints
> after a stern warning or two which depends on frequency, a few per day
> is very different than one or two per month, and what to do with those
> phony AOL TOS complaints which almost always mean "I asked to be on
> this list but I forgot how to get off so maybe if I keep clicking the
> spam button..."?

You run a botique provider of shells that - at least today - almost
exclusively caters to geeks.  You arent as likely to pick up genuinely
badhat spamming customers as the rest of us large ISPs are - and the
large colo farms (he.net, softlayer etc) are even more vulnerable to
this kind of thing.

Feedback loops (such as those AOL provide, or we provide - and we were
the second ISP after AOL to offer ARF'd feedback loops) are about the
best tool any ISP has available to it, to get near real time spam
reports.

You're a corner case.  And an opinionated corner case at that.  That
doesnt change just how useful FBLs are to the vast majority of
consumer ISPs out there.

--srs