Re: UDP port 80 DDoS attack

[John Kristoff]

On Sun, 5 Feb 2012 18:36:13 -0500
Ray Gasnick III  wrote:

> Only solution thus far was to dump the victim IP address in our block
> into the BGP Black hole community with one of our 2 providers and
> completely stop advertising to the other.

Drew mentioned udp.pl and I also it could have been this script running
on some compromised Unix-based host(s) as well.  If the traffic did not
appear to be widely distributed, that is, not spoofed, then this is
even more likely.  If that was the case, filtering based on the sender
address(es) may help better mitigate the attack without taking the
target entirely offline for everyone else.

John

Dear RIPE: Please don't encourage phishing

[Steven Bellovin]

I received the enclosed note, apparently from RIPE (and the headers check out).
Why are you sending messages with clickable objects that I'm supposed to use to
change my password?

---

From: ripe_dbannou...@ripe.net
Subject: Advisory notice on passwords in the RIPE Database
Date: February 9, 2012 1:16:15 PM EST
To: 

[Apologies for duplicate e-mails]

Dear Colleagues,

We are contacting you with some advice on the passwords used in the RIPE
Database.  There is no immediate concern and this notice is only advisory.
At the request of the RIPE community, the RIPE NCC recently deployed an
MD5 password hash change.

Before this change was implemented, there was a lot of discussion on the
Database Working Group mailing list about the vulnerabilities of MD5
passwords with public hashes.  The hashes can now only be seen by the user
of the MNTNER object.  As a precaution, now that the hashes are hidden,
we strongly recommend that you change all MD5 passwords used by your MNTNER
objects in the RIPE Database at your earliest convenience.  When choosing
new passwords, make them as strong as possible.

To make it easier for you to change your password(s) we have improved
Webupdates.  On the modify page there is an extra button after the "auth:"
attribute field.  Click this button for a pop up window that will encrypt
a password and enter it directly into the "auth:" field.

Webupdates: https://apps.db.ripe.net/webupdates/search.html

There is a RIPE Labs article explaining details of the security changes
and the new process to modify a MNTNER object in the RIPE Database:
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database

We are sending you this email because this address is referenced in the
MNTNER objects in the RIPE Database listed below.

If you have any concerns about your passwords or need further advice please
contact our Customer Services team at ripe-...@ripe.net.  (You cannot reply
to this email.)

Regards,

Denis Walker
Business Analyst
RIPE NCC Database Group

Referencing MNTNER objects in the RIPE Database:
maint-rgnet

Re: Dear RIPE: Please don't encourage phishing

[Richard Barnes]

So because of phishing, nobody should send messages with URLs in them?



On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin  wrote:
> I received the enclosed note, apparently from RIPE (and the headers check 
> out).
> Why are you sending messages with clickable objects that I'm supposed to use 
> to
> change my password?
>
> ---
>
> From: ripe_dbannou...@ripe.net
> Subject: Advisory notice on passwords in the RIPE Database
> Date: February 9, 2012 1:16:15 PM EST
> To: 
>
> [Apologies for duplicate e-mails]
>
> Dear Colleagues,
>
> We are contacting you with some advice on the passwords used in the RIPE
> Database.  There is no immediate concern and this notice is only advisory.
> At the request of the RIPE community, the RIPE NCC recently deployed an
> MD5 password hash change.
>
> Before this change was implemented, there was a lot of discussion on the
> Database Working Group mailing list about the vulnerabilities of MD5
> passwords with public hashes.  The hashes can now only be seen by the user
> of the MNTNER object.  As a precaution, now that the hashes are hidden,
> we strongly recommend that you change all MD5 passwords used by your MNTNER
> objects in the RIPE Database at your earliest convenience.  When choosing
> new passwords, make them as strong as possible.
>
> To make it easier for you to change your password(s) we have improved
> Webupdates.  On the modify page there is an extra button after the "auth:"
> attribute field.  Click this button for a pop up window that will encrypt
> a password and enter it directly into the "auth:" field.
>
> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>
> There is a RIPE Labs article explaining details of the security changes
> and the new process to modify a MNTNER object in the RIPE Database:
> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>
> We are sending you this email because this address is referenced in the
> MNTNER objects in the RIPE Database listed below.
>
> If you have any concerns about your passwords or need further advice please
> contact our Customer Services team at ripe-...@ripe.net.  (You cannot reply
> to this email.)
>
> Regards,
>
> Denis Walker
> Business Analyst
> RIPE NCC Database Group
>
> Referencing MNTNER objects in the RIPE Database:
> maint-rgnet
>
>
>
>
>
>

Re: Dear RIPE: Please don't encourage phishing

[Steven Bellovin]

If they're intended as a path to log in with a typed password, that's correct.
Sad, but correct.

On Feb 10, 2012, at 12:18 PM, Richard Barnes wrote:

> So because of phishing, nobody should send messages with URLs in them?
> 
> 
> 
> On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin  wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check 
>> out).
>> Why are you sending messages with clickable objects that I'm supposed to use 
>> to
>> change my password?
>> 
>> ---
>> 
>> From: ripe_dbannou...@ripe.net
>> Subject: Advisory notice on passwords in the RIPE Database
>> Date: February 9, 2012 1:16:15 PM EST
>> To: 
>> 
>> [Apologies for duplicate e-mails]
>> 
>> Dear Colleagues,
>> 
>> We are contacting you with some advice on the passwords used in the RIPE
>> Database.  There is no immediate concern and this notice is only advisory.
>> At the request of the RIPE community, the RIPE NCC recently deployed an
>> MD5 password hash change.
>> 
>> Before this change was implemented, there was a lot of discussion on the
>> Database Working Group mailing list about the vulnerabilities of MD5
>> passwords with public hashes.  The hashes can now only be seen by the user
>> of the MNTNER object.  As a precaution, now that the hashes are hidden,
>> we strongly recommend that you change all MD5 passwords used by your MNTNER
>> objects in the RIPE Database at your earliest convenience.  When choosing
>> new passwords, make them as strong as possible.
>> 
>> To make it easier for you to change your password(s) we have improved
>> Webupdates.  On the modify page there is an extra button after the "auth:"
>> attribute field.  Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.
>> 
>> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>> 
>> There is a RIPE Labs article explaining details of the security changes
>> and the new process to modify a MNTNER object in the RIPE Database:
>> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>> 
>> We are sending you this email because this address is referenced in the
>> MNTNER objects in the RIPE Database listed below.
>> 
>> If you have any concerns about your passwords or need further advice please
>> contact our Customer Services team at ripe-...@ripe.net.  (You cannot reply
>> to this email.)
>> 
>> Regards,
>> 
>> Denis Walker
>> Business Analyst
>> RIPE NCC Database Group
>> 
>> Referencing MNTNER objects in the RIPE Database:
>> maint-rgnet
>> 
>> 
>> 
>> 
>> 
>> 
> 


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

Re: Dear RIPE: Please don't encourage phishing

[Randy Bush]

> So because of phishing, nobody should send messages with URLs in them?

more and more these days, i have taken to not clicking the update messages, 
but going to the web site manyually to get it.

wy to much phishing, and it is getting subtle and good.

randy

Re: Dear RIPE: Please don't encourage phishing

[Corey Quinn]

On Feb 10, 2012, at 9:29 AM, Randy Bush wrote:

>> So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.
> 
> wy to much phishing, and it is getting subtle and good.


Concur.

It seems as if they're no longer written by non-native English speakers, which 
goes a long way towards making them more insidious.  While still perfectly 
intelligible, most folks who use English as a second language don't speak in 
the same voice as, say, Wells Fargo corporate communications.


-- Corey 

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Dear RIPE: Please don't encourage phishing

[William Herrin]

On Fri, Feb 10, 2012 at 12:18 PM, Richard Barnes
 wrote:
> On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin  wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check 
>> out).
>> Why are you sending messages with clickable objects that I'm supposed to use 
>> to
>> change my password?
>> [...]
>> attribute field.  Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.

> So because of phishing, nobody should send messages with URLs in them?

url != clickable object


No problem with URLs in email.

No problem with clickable objects that are unrelated to security.

Minor problem with URLs that lead to changing passwords but can be
mitigated by making the URL very plain and easy to read, even by a
non-techie. They'll at least have to see the thing, even if the mail
client automagically makes it clickable.

Big problem with clickable objects which lead to PII (personally
identifiable information) or passwords. That's how phishing works -- a
disguised url that you either see at all or whose incorrect nature
slips right past your brain. The only known working solution is to
train folks to *never* click security-related URLs in email. Copy and
paste only, and only if they're readable and read right.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Dear RIPE: Please don't encourage phishing

[Jay Ashworth]

> It seems as if they're no longer written by non-native English
> speakers, which goes a long way towards making them more insidious.
> While still perfectly intelligible, most folks who use English as a
> second language don't speak in the same voice as, say, Wells Fargo
> corporate communications.

Most people who use English as their milk language don't speak in the same
voice as Wells Fargo Corporate Communications.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Dear RIPE: Please don't encourage phishing

[Leo Bicknell]

In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.
> 
> wy to much phishing, and it is getting subtle and good.

We know how to sign and encrypt web sites.

We know how to sign and encrypt e-mail.

We even know how to compare keys between the web site and e-mail via a
variety of mechanisms.

We know how to sign DNS.

Remind me again why we live in this sad word Randy (correcly) described?

There's no reason my mail client shouldn't validate the signed e-mail
came from the same entity as the signed web site I'd previously logged
into, and give me a green light that the link actually points to said
same web site with the same key.  It should be transparent, and secure
for the user.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgp2Levs78GW0.pgp
Description: PGP signature

Re: Dear RIPE: Please don't encourage phishing

[Dan White]

The line gets crossed when you send an unsolicited message that includes a
clickable change password link, that a phisher would find interesting
to emulate.

After the fact, if a phisher gets one of your customers to click on such a
link, you'd like to tell them them in response, or preemptively, that your
company never asks for sensitive information via email.

With good policies in place, the customer should not be receiving clickable
links via email that ask them for a password, except for a scenario where
they've actively generated that email in response to an "I forgot my
password" link on a website.

On 02/10/12 09:18 -0800, Richard Barnes wrote:

So because of phishing, nobody should send messages with URLs in them?



On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin  wrote:

I received the enclosed note, apparently from RIPE (and the headers check out).
Why are you sending messages with clickable objects that I'm supposed to use to
change my password?

---

From: ripe_dbannou...@ripe.net
Subject: Advisory notice on passwords in the RIPE Database
Date: February 9, 2012 1:16:15 PM EST
To: 

[Apologies for duplicate e-mails]

Dear Colleagues,

We are contacting you with some advice on the passwords used in the RIPE
Database.  There is no immediate concern and this notice is only advisory.
At the request of the RIPE community, the RIPE NCC recently deployed an
MD5 password hash change.

Before this change was implemented, there was a lot of discussion on the
Database Working Group mailing list about the vulnerabilities of MD5
passwords with public hashes.  The hashes can now only be seen by the user
of the MNTNER object.  As a precaution, now that the hashes are hidden,
we strongly recommend that you change all MD5 passwords used by your MNTNER
objects in the RIPE Database at your earliest convenience.  When choosing
new passwords, make them as strong as possible.

To make it easier for you to change your password(s) we have improved
Webupdates.  On the modify page there is an extra button after the "auth:"
attribute field.  Click this button for a pop up window that will encrypt
a password and enter it directly into the "auth:" field.

Webupdates: https://apps.db.ripe.net/webupdates/search.html

There is a RIPE Labs article explaining details of the security changes
and the new process to modify a MNTNER object in the RIPE Database:
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database

We are sending you this email because this address is referenced in the
MNTNER objects in the RIPE Database listed below.

If you have any concerns about your passwords or need further advice please
contact our Customer Services team at ripe-...@ripe.net.  (You cannot reply
to this email.)

Regards,

Denis Walker
Business Analyst
RIPE NCC Database Group

Referencing MNTNER objects in the RIPE Database:
maint-rgnet











--
Dan White
BTC Broadband
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@olp.net
http://www.btcbroadband.com

PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

[Jeroen Massar]

On 2012-02-10 18:37 , Leo Bicknell wrote:
[..]

> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

That is a rather nice idea. Most people, especially the common ones, do
not use PGP or heck even S/MIME though and only when one is included in
the web-of-trust can one actually verify these. Of course when that is
done, one should be able to match up email address and website URL quite
easily and your trick will work, at least one can then state:
  "the sender, who is verified by trust, is pointing to his/her
   own website."

The problem still lies in the issue that most people, even on this very
list, do not use PGP or S/MIME. (and that there are two standards does
not help much there either ;)

Greets,
 Jeroen

Re: Dear RIPE: Please don't encourage phishing

[Randy Bush]

> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

my paranoid side is not comfortable with the certs that come for free
with my browser.  see the ietf dane wg.

randy

Re: Dear RIPE: Please don't encourage phishing

[Randy Bush]

> While still perfectly intelligible, most folks who use English as a
> second language don't speak in the same voice as, say, Wells Fargo
> corporate communications.

yep.  if it's intelligible, it can't really be from wells fargo corp
comms.

randy

Re: Dear RIPE: Please don't encourage phishing

[Valdis . Kletnieks]

On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:

> We know how to sign and encrypt web sites.
>
> We know how to sign and encrypt e-mail.
>
> We even know how to compare keys between the web site and e-mail via a
> variety of mechanisms.
>
> We know how to sign DNS.
>
> Remind me again why we live in this sad word Randy (correcly) described?

Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
supposed to be smarter than this."
Anakin Skywalker: "Apparently not."



pgp0ByzvhMKTR.pgp
Description: PGP signature

Re: Dear RIPE: Please don't encourage phishing

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> Big problem with clickable objects which lead to PII (personally
> identifiable information) or passwords. That's how phishing works -- a
> disguised url that you either see at all or whose incorrect nature
> slips right past your brain. The only known working solution is to
> train folks to *never* click security-related URLs in email. Copy and
> paste only, and only if they're readable and read right.

And right there, Bill, is the part we so rarely understand, and it kills us:

Even lots of *technical* people just don't understand what "a security-
related URL" *is*, and there's almost always no way to teach them.

So it's necessary to throw the baby out with the bathwater, and tell them
never to click on a link...  MUA's that support HTML at all, much less
they fail to tell the user when a text URL doesn't match the actual link,
are the underlying culprits here...

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

[Leo Bicknell]

In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar 
wrote:
> The problem still lies in the issue that most people, even on this very
> list, do not use PGP or S/MIME. (and that there are two standards does
> not help much there either ;)

The problem space is still certificate management.

I bet (nearly) everyone on the list uses an e-mail client that can
decode S/MIME.  mutt, pine, Outlook, OSX Mail, gmail, they all do
it.  We all have browsers that do SSL.

OSX at least has a central certificate store (Keychain), although
it's not up to the tasks of the world I wish to have.  Other OS's
provide no central store, so each application maintains their own
key store.  We have a very real problem of pre-loading the key
store, for instance root certificate trust for X.509 certificates.

We need a central certificate store on every platform, easy, secure ways
to transfer/sync it (to say, moble devices), and a bit of UI goo.
Imagine a capability as simple as being able to add a description to a
cert in your key store.  I should be able to download my bank's cert,
verify it (call and check finger print, check a trusted third party,
web of trust, probably multiple ways, automated, would be best) and then
tag it "Leo's Bank".

When I get e-mail from it, or go to it with my web browser it should now
say "Leo's Bank" in all of my software, telling me not only do I have
the little padlock, but it's the certificate I personally validated.

When I click on a link in e-mail it should pass the URL AND KEY to
the next program (e.g. my browser).  My browser can then silently
load if they are the same, or give me a big pop up "The person who
sent this e-mail is different from the person who runs this web
site."

It's all UI.  No new technology, protocols, encryption formats or other
things are needed.  It's making end user software act in a responsible
way.

Of course I'd also prefer my bank allowed me to provide my certificate
to them, and they crypto authenticated me (perhaps in addition to
passwords and pins).  This should all be two-way.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpSWz9uFJWsW.pgp
Description: PGP signature

Re: Dear RIPE: Please don't encourage phishing

[-Hammer-]

Leo,
This has nothing to do with the competency of the folks on the 
nanog list. It's a safe rule in general. Why? Because the stupid on the 
Internet outnumbers all of us. It's just easier to not send clickable 
links then it is to have the call center lit up because your users are 
getting hijacked.


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/10/2012 11:51 AM, valdis.kletni...@vt.edu wrote:

On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:


We know how to sign and encrypt web sites.

We know how to sign and encrypt e-mail.

We even know how to compare keys between the web site and e-mail via a
variety of mechanisms.

We know how to sign DNS.

Remind me again why we live in this sad word Randy (correcly) described?

Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
 supposed to be smarter than this."
Anakin Skywalker: "Apparently not."

Re: Dear RIPE: Please don't encourage phishing

[Randy Bush]

> We know how to sign and encrypt e-mail.

there is a public key distribution and trust problem

> We know how to sign DNS.

not very reliably yet

randy

Iran blocking essentially all encyrpted protocols

[Ryan Malayter]

Haven't seen this come through on NANOG yet:
http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars

Can anyone with the ability confirm that TCP/443 traffic from Iran has
stopped?

Re: Iran blocking essentially all encyrpted protocols

[Donald Eastlake]

Probably better than Iran doing man-in-the-middle...

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Fri, Feb 10, 2012 at 1:26 PM, Ryan Malayter  wrote:
> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?
>

Re: Iran blocking essentially all encyrpted protocols

[Jay Ashworth]

- Original Message -
> From: "Ryan Malayter" 

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
> 
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?

Lauren scooped you on Privacy by about 6 minutes.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Iran blocking essentially all encyrpted protocols

[James Smith]

correct, it's down in Iran,
A few of my contacts got back to me confirming this  a few hours ago.

-Original Message- 
From: Jay Ashworth

Sent: Friday, February 10, 2012 2:29 PM
To: NANOG
Subject: Re: Iran blocking essentially all encyrpted protocols

- Original Message -

From: "Ryan Malayter" 



Haven't seen this come through on NANOG yet:
http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars

Can anyone with the ability confirm that TCP/443 traffic from Iran has
stopped?


Lauren scooped you on Privacy by about 6 minutes.  :-)

Cheers,
-- jra
--
Jay R. Ashworth  Baylink 
j...@baylink.com
Designer The Things I Think   RFC 
2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover 
DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 
1274 

Re: Dear RIPE: Please don't encourage phishing

[William Herrin]

On Fri, Feb 10, 2012 at 1:00 PM, Jay Ashworth  wrote:
>> From: "William Herrin" 
>> Big problem with clickable objects which lead to PII (personally
>> identifiable information) or passwords. That's how phishing works -- a
>> disguised url that you either see at all or whose incorrect nature
>> slips right past your brain. The only known working solution is to
>> train folks to *never* click security-related URLs in email. Copy and
>> paste only, and only if they're readable and read right.
>
> And right there, Bill, is the part we so rarely understand, and it kills us:
>
> Even lots of *technical* people just don't understand what "a security-
> related URL" *is*, and there's almost always no way to teach them.
>
> So it's necessary to throw the baby out with the bathwater, and tell them
> never to click on a link...

Hi Jay,

And if we could just train people to never send or accept email
attachments, we could get rid of email-spread viruses. Not gonna
happen -- the functionality is too useful.

Security isn't just about what you can train someone to do... it's
also about what you can convince them to do when you're not standing
behind them watching -- the instructions that they're willing to
internalize. You can't convince people never to click links in an
email. It's too useful.

You might, however, be able to convince the average person that if a
link they clicked from an email asks for a password or asks for any
personal information then the message was probably from an
impersonator trying to steal the user's identity and they should
report it immediately lest they be victimized.

Regards,
Bill


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Dear RIPE: Please don't encourage phishing

[Jay Ashworth]

 Original Message -
> From: "William Herrin" 

> And if we could just train people to never send or accept email
> attachments, we could get rid of email-spread viruses. Not gonna
> happen -- the functionality is too useful.
> 
> Security isn't just about what you can train someone to do... it's
> also about what you can convince them to do when you're not standing
> behind them watching -- the instructions that they're willing to
> internalize. You can't convince people never to click links in an
> email. It's too useful.

I did admit that it was throwing the baby out with the bathwater.

Being able to drive across someone's golf course to get to work is
convenient for me as well, but I'm still forbidden to do it.  This is a
tragedy of the commons problem -- since the biggest target for zombies
on PCs is probably spambots ...

> You might, however, be able to convince the average person that if a
> link they clicked from an email asks for a password or asks for any
> personal information then the message was probably from an
> impersonator trying to steal the user's identity and they should
> report it immediately lest they be victimized.

Yup.  Just like Steve just did in the posting that started this.

Y'know: the thing that only looked like a phish.

Cheers,
-- jr 'and don't even get me started on e-cards' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 11 Feb, 2012

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  397602
Prefixes after maximum aggregation:  169606
Deaggregation factor:  2.34
Unique aggregates announced to Internet: 192311
Total ASes present in the Internet Routing Table: 40086
Prefixes per ASN:  9.92
Origin-only ASes present in the Internet Routing Table:   32739
Origin ASes announcing only one prefix:   15528
Transit ASes present in the Internet Routing Table:5400
Transit-only ASes present in the Internet Routing Table:147
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  33
Max AS path prepend of ASN (48687)   24
Prefixes from unregistered ASNs in the Routing Table:   328
Unregistered ASNs in the Routing Table: 127
Number of 32-bit ASNs allocated by the RIRs:   2272
Number of 32-bit ASNs visible in the Routing Table:1947
Prefixes from 32-bit ASNs in the Routing Table:4674
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:137
Number of addresses announced to Internet:   2513929424
Equivalent to 149 /8s, 215 /16s and 132 /24s
Percentage of available address space announced:   67.8
Percentage of allocated address space announced:   67.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   92.0
Total number of prefixes smaller than registry allocations:  168841

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:98087
Total APNIC prefixes after maximum aggregation:   31681
APNIC Deaggregation factor:3.10
Prefixes being announced from the APNIC address blocks:   94410
Unique aggregates announced from the APNIC address blocks:39147
APNIC Region origin ASes present in the Internet Routing Table:4652
APNIC Prefixes per ASN:   20.29
APNIC Region origin ASes announcing only one prefix:   1239
APNIC Region transit ASes present in the Internet Routing Table:737
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 20
Number of APNIC region 32-bit ASNs visible in the Routing Table:143
Number of APNIC addresses announced to Internet:  635706656
Equivalent to 37 /8s, 228 /16s and 29 /24s
Percentage of available APNIC address space announced: 80.6

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
   182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
   219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:148238
Total ARIN prefixes after maximum aggregation:75329
ARIN Deaggregation factor: 1.97
Prefixes being announced from the ARIN address blocks:   120188
Unique aggregates announced from the ARIN address blocks: 49415
ARIN Region origin ASes present in the Internet Routing Table:14905
ARIN Prefixes per ASN: 8.06
ARIN Region origin ASes announcing only one prefix:5689
ARIN

Re: Iran blocking essentially all encyrpted protocols

[Shahab Vahabzadeh]

Yes I am from Iran and outgoing TCP/443 has been stoped ;)

--
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

On Feb 10, 2012, at 9:56 PM, Ryan Malayter  wrote:

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
> 
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?
> 

Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

[Ryan Malayter]

On Feb 10, 12:01 pm, Leo Bicknell  wrote:
> OSX at least has a central certificate store (Keychain), although
> it's not up to the tasks of the world I wish to have.  Other OS's
> provide no central store, so each application maintains their own
> key store.

Windows has had its own centralized certificate store and APIs since
NT 4.0's release in 1996.

Firefox and Java are the only mainstream software can think of on
Windows that insists on using their own certificate stores (really
just a "pile of world-readable files") instead of the built-in per-
machine+per-user certificate store on Windows.

Re: Dear RIPE: Please don't encourage phishing

[JC Dill]

On 10/02/12 10:00 AM, Jay Ashworth wrote:

Even lots of*technical*  people just don't understand what "a security-
related URL"*is*, and there's almost always no way to teach them.


Freakonomics recently aired a story about the problem of getting Doctors 
to follow hand hygiene rules and wash their hands as frequently as they 
are supposed to (upon entering and leaving each patient's room) to avoid 
spreading disease.  One of the biggest problems with changing behavior 
with doctors (and with technical people) is that the smarter people are, 
the more they chafe at being told they aren't doing things the correct way.


The most effective step they took to counter-act the hand-washing 
problems was using a screen-saver on all the public terminals, showing 
the consequences of not-washing - an image of a petri dish showing the 
bacteria results from a hand-print of a doctor's hand.


http://www.freakonomics.com/2012/01/24/how-to-get-doctors-to-wash-their-hands-visual-edition/


If you wanted to have a similar effect at $workplace, try a similar 
visual (e.g. a mockup of 2 screenshots, first clicking on a link in 
email then typing in a password on a webpage with a phishing URL (with a 
typo)) as the screen saver on all company computers; as the first slide 
in all in-house ppt presentations; on the wall at all card-lock entry 
doors, etc.


jc

Re: Dear RIPE: Please don't encourage phishing

[Rich Kulawiec]

On Fri, Feb 10, 2012 at 12:28:22PM -0500, Steven Bellovin wrote:
> If they're intended as a path to log in with a typed password, that's correct.
> Sad, but correct.

I agree.  Training your customers/clients to click on URLs in email
messages is precisely equivalent to training them to be phish victims.

I teach people to (carefully!) bookmark the sites that they use which
require passwords, and to always use those bookmarks -- that is, *never*
to use the links in any mail message or on any web page.

(Of course, an attacker in control of their browser could manipulate the
bookmarks, but there is little reason for an attacker who's already gotten
that far to do so.)

---rsk

Re: Dear RIPE: Please don't encourage phishing

[Jay Ashworth]

- Original Message -
> From: "JC Dill" 

> If you wanted to have a similar effect at $workplace, try a similar
> visual (e.g. a mockup of 2 screenshots, first clicking on a link in
> email then typing in a password on a webpage with a phishing URL (with a
> typo)) as the screen saver on all company computers; as the first slide
> in all in-house ppt presentations; on the wall at all card-lock entry
> doors, etc.

The problem is you need the 3rd visual...

a picture of an abandoned factory, with the doors flapping in the wind, 
bceause the company went out of business because someone got spearphished.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Dear RIPE: Please don't encourage phishing

[Valdis . Kletnieks]

On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:

> a picture of an abandoned factory, with the doors flapping in the wind,
> bceause the company went out of business because someone got spearphished.

Has this ever been spotted in the wild?  Serious question - most of the 
well-publicized
spearphishing attacks lately the victim company is still around.


pgpIR7m8TZsHU.pgp
Description: PGP signature

Re: Dear RIPE: Please don't encourage phishing

[Jay Ashworth]

- Original Message -
> From: "Valdis Kletnieks" 

> On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:
> > a picture of an abandoned factory, with the doors flapping in the wind,
> > bceause the company went out of business because someone got spearphished.
> 
> Has this ever been spotted in the wild? Serious question - most of the
> well-publicized spearphishing attacks lately the victim company is still 
> around.

I don't know that we would have any way to know that a demised company went
down due to a spearphish... but yes, I was exaggerating.

Cheers,
-- jr 'hyperbole and a half!' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Iran blocking essentially all encyrpted protocols

[Marshall Eubanks]

And in response

http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/

(quoting) :

“Basically, say you want to look like an XMPP chat instead of SSL,” he
writes to me, referring to a protocol for instant messaging as the
decoy for the encrypted SSL communications. “Obfsproxy should start
up, you choose XMPP, and obfsproxy should emulate XMPP to the point
where even a sophisticated [deep packet inspection] device cannot find
anything suspicious.”

Regards
Marshall

On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
 wrote:
> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>
> --
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
>
> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90
>
> On Feb 10, 2012, at 9:56 PM, Ryan Malayter  wrote:
>
>> Haven't seen this come through on NANOG yet:
>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>
>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>> stopped?
>>
>

Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

[Leo Bicknell]

In a message written on Fri, Feb 10, 2012 at 11:11:18AM -0800, Ryan Malayter 
wrote:
> Windows has had its own centralized certificate store and APIs since
> NT 4.0's release in 1996.

You are correct that I maligned Windows in a way I shouldn't have
done.  Indeed, I've been very impressed with the software they make
to manage certificates in the enterprise before, making it quite
easy to roll out per user certificates for VPN's or E-Mail and dump
it in the certificate store.

I think my view was incorrectly colored by the fact that the API
is not used by many programs (open source in particular) where as
OSX has had some traction with the Keychain.

It would be nice to get something approximating a cross platform API,
even if all that means is the ability to do the same operations on all
major platforms.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpdkCr8BT51C.pgp
Description: PGP signature

Re: Dear RIPE: Please don't encourage phishing

[Steven Bellovin]

On Feb 10, 2012, at 12:29 30PM, Randy Bush wrote:

>> So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.

Yup -- I wrote about that a while back 
(https://www.cs.columbia.edu/~smb/blog/2011-10/2011-10-02.html)
> 
> wy to much phishing, and it is getting subtle and good.
> 


What's the line -- "I know I'm paranoid, but am I paranoid enough?"

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

Re: Dear RIPE: Please don't encourage phishing

[Steven Bellovin]

On Feb 10, 2012, at 12:37 01PM, Leo Bicknell wrote:

> In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush 
> wrote:
>> more and more these days, i have taken to not clicking the update messages, 
>> but going to the web site manyually to get it.
>> 
>> wy to much phishing, and it is getting subtle and good.
> 
> We know how to sign and encrypt web sites.
> 
> We know how to sign and encrypt e-mail.
> 
> We even know how to compare keys between the web site and e-mail via a
> variety of mechanisms.
> 
> We know how to sign DNS.
> 
> Remind me again why we live in this sad word Randy (correcly) described?
> 
> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

The really hard parts are (a) getting the users to pay attention to the
validation state (or, more precisely, the lack thereof on a phishing
email, and (b) get them to do it *correctly*.

Some of the browser password managers have protection against phishing as
a very useful side-effect: if they don't recognize the URL, they won't pony
up the correct login and password.  That's much better than hoping that
someone notices the absence of a little icon that means "this was signed".

The "correctly" part has to do with the PKI mess.


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

Re: Dear RIPE: Please don't encourage phishing

[Jay Ashworth]

- Original Message -
> From: "Steven Bellovin" 

> What's the line -- "I know I'm paranoid, but am I paranoid enough?"

"Just because people say you're paranoid, that doesn't mean that there
*aren't* people out to get you."

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

[William Herrin]

On Fri, Feb 10, 2012 at 1:01 PM, Leo Bicknell  wrote:
> In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar 
> wrote:
>> The problem still lies in the issue that most people, even on this very
>> list, do not use PGP or S/MIME. (and that there are two standards does
>> not help much there either ;)
>
> The problem space is still certificate management.

The problem space is that most folks won't catch the difference
between an email and link from ripe.net, ripe.org and ripe.ca. The
game is lost long before a purely technical version of validating the
message source becomes an issue.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

couple of questions regarding 'lifeline' and large scale nat...

[Eric J Esslinger]

We're toying with the idea of a low bitrate 'lifeline' internet on our cable 
system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit rates 
are you providing.
Second question, though 'real' internet customers all get real IP's, what would 
you think of doing something like this with 'large scale' nat instead. 
Understand, we're only talking about basic internet, something like a 256k/96k 
(or similar) connect, not something that would be used by a serious user. (One 
thing we are looking at is some older dial up users we still have, most of 
which could go onto cable just fine but don't want to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand 
customers for this. We're not a large ISP/cable company by any means.

__
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and is 
intended for the person/entity to whom it was originally addressed. Any use by 
others is strictly prohibited.
<>

Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)

[Leo Bicknell]

In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin 
wrote:
> The problem space is that most folks won't catch the difference
> between an email and link from ripe.net, ripe.org and ripe.ca. The
> game is lost long before a purely technical version of validating the
> message source becomes an issue.

You're reply is along the lines of what several other folks have
told me privately, and I think they all miss the mark of where I
am going with my suggestion.

Hypothetically, I get an e-mail from ripe.ca, which uses some trick
(perhaps as simple as HTML text and link that go to different places)
to visually show me ripe.net and actually sends me to ripe.org.

Let's also assume I have a ripe.net account and have been to that
web site before.

The software can do a pile of things that make life better for the user:

1) When I reach ripe.org (from the phish above), my browser can say:

   "This is an SSL web site asking for a login and password, and yet,
you've never been here before.  Maybe you would prefer to register,
or leave if you came here incorrectly."

   That's all client side UI, and would make even novice users stop
   and think about what happened.

2) Let's say the e-mail was signed, by ripe.ca, the original sender.
   When my e-mail client passes the URL to my browser, it can also pass
   the details of the ripe.ca key.  My browser can then say "You got
   an e-mail from Key ABC, but went to a web site run by XYZ, are you
   sure this is what you want to do?"  Of course if everything matches,
   it can be silent.

Specifically I am NOT suggesting to ever trust a root-CA, or the
details in a certificate.  Indeed, browsers could ship with no
certificates what so ever in my scheme.  The key is comparing
multiple sources of information.  Most folks might not know the
difference between ripe.ca and ripe.net.  The existing CA scheme
may allow both of them to get the common name "Réseaux IP Européens",
confusing even the technical who look close.  But it's trivial for
the software to say Cert in E-mail != Cert in Web, or even that
they don't have a common branch in the tree (in a large org they
may have the same parent, for instance).

As I've also said, a good UI feature would be the ability to add a
description to a cert locally.  Once I'm sure my banks web site is legit
I should be able to add "Leo's Bank" in the cert store locally.  Now
when my web browser or e-mail client use that cert to validate a message
they can display "Leo's Bank" next to it.  I can easily look for that
and know I went back to the same place.  I click on a link in my e-mail
and see no description, I know something went wrong.

Does my scheme stop all phishing.  Heck no.  If we wait for a perfect
solution we'll never have any solution.  Look at NANOG.  Bandy Rush is
here somewhere.  It's why many years ago I set my mailer to PGP all
e-mail to NANOG.  See an e-mail from me not signed, don't trust it.
Does that stop all impersonation on NANOG.  Heck no, but if we all did
it, and subscribed to the web of trust, it would all but stop it.

Users hate encryption and ignore the warnings not because they don't
want to be secure, or are idiots.  They do it because the darn software
is broken, confusing, and has the worst UI's ever invented.  If the
industry fixes it, encryption will be much more widespread.  Small
steps, like banks allowing users to upload an cert to their account
profile, and then communicate via two-way authenticated e-mail would go
a long way to traning the user community how this should work.  End user
ISP's (cable, DSL) issuing e-mail certs automatically and installing
them as part of their install package would be a quantum leap forward.

It's not hard, people just don't do it.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpUbeyXKuQ3e.pgp
Description: PGP signature

Re: couple of questions regarding 'lifeline' and large scale nat...

[Leo Bicknell]

In a message written on Fri, Feb 10, 2012 at 03:19:24PM -0600, Eric J Esslinger 
wrote:
> First question, if you happen to be doing something like this, what bit rates 
> are you providing.

Comcast has a program with some of the best marketing around it right
now, their Internet Essentials service: http://www.internetessentials.com/

$9.95/month, 1.5Mbps down, 384kbps up.

> Second question, though 'real' internet customers all get real IP's, what 
> would you think of doing something like this with 'large scale' nat instead.

Carriers do not want to run NAT's.  You can go read the archives of the
CGN (Carrier Grade NAT) discussions where folks are looking at moving
the NAT into the service provider due to IPv4 exhaustion.

UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
passthrough), combined with the problems of some applications that
make thousands of TCP connections in a short order eating up ports
makes it a nightmare to manage and debug.  Of course, if they are
doing illegal things you'd better keep some detailed records of who did
what when a LEO comes knocking.

The key to a low cost service is making it as low cost as possible,
moving the NAT inside the carrier will had a huge amount of headache and
support costs, not what you want.

A possibly relevant question with IPv4 exhaustion coming is could you
make this service IPv6 only so you don't have to find IPv4 addresses for
it.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpAil77rYEUt.pgp
Description: PGP signature

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 02-Feb-12 -to- 09-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS840253549  3.4%  29.9 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS28683   32704  2.1% 536.1 -- BENINTELECOM
 3 - AS982926878  1.7%  39.6 -- BSNL-NIB National Internet 
Backbone
 4 - AS12479   26390  1.7% 303.3 -- UNI2-AS France Telecom Espana SA
 5 - AS45271   23588  1.5% 168.5 -- ICLNET-AS-AP 5th Floor, Windsor 
Building, Off: CST Road
 6 - AS32528   22752  1.4%7584.0 -- ABBOTT Abbot Labs
 7 - AS845221248  1.3%  52.7 -- TE-AS TE-AS
 8 - AS23154   20456  1.3%6818.7 -- SANMINA-SCI Sanmina-SCI 
Corporation
 9 - AS580019469  1.2%  64.0 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
10 - AS755217101  1.1%  19.6 -- VIETEL-AS-AP Vietel Corporation
11 - AS24560   16978  1.1%  39.7 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
12 - AS20632   15343  1.0%1180.2 -- PETERSTAR-AS PeterStar
13 - AS211815208  1.0%  17.4 -- RELCOM-AS OOO "NPO Relcom"
14 - AS17974   14308  0.9%  15.3 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
15 - AS650312775  0.8%   7.6 -- Axtel, S.A.B. de C.V.
16 - AS606612372  0.8%6186.0 -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
17 - AS597611800  0.8% 119.2 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
18 - AS671311470  0.7%  25.9 -- IAM-AS
19 - AS29126   11373  0.7%   11373.0 -- DATIQ-AS Datiq B.V.
20 - AS12975   10309  0.7%  45.4 -- PALTEL-AS PALTEL Autonomous 
System


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS29126   11373  0.7%   11373.0 -- DATIQ-AS Datiq B.V.
 2 - AS32528   22752  1.4%7584.0 -- ABBOTT Abbot Labs
 3 - AS23154   20456  1.3%6818.7 -- SANMINA-SCI Sanmina-SCI 
Corporation
 4 - AS606612372  0.8%6186.0 -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
 5 - AS5868 1882  0.1%1882.0 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 6 - AS8163 1257  0.1%1257.0 -- METROTEL REDES S.A.
 7 - AS20632   15343  1.0%1180.2 -- PETERSTAR-AS PeterStar
 8 - AS53362 882  0.1% 882.0 -- MIXIT-AS - Mixit, Inc.
 9 - AS21271 810  0.1% 810.0 -- SOTELMABGP
10 - AS27704 595  0.0% 595.0 -- Tiendas Comercial Mexicana, 
S.A. de C.V.
11 - AS174083497  0.2% 582.8 -- ABOVE-AS-AP AboveNet 
Communications Taiwan
12 - AS51896 567  0.0% 567.0 -- HRINGDU-AS Hringdu ehf
13 - AS1997 1643  0.1% 547.7 -- IBMDES-AS - IBM Dallas 
Engineering & Scientific
14 - AS28683   32704  2.1% 536.1 -- BENINTELECOM
15 - AS36980 512  0.0% 512.0 -- JOHNHOLT-ASN
16 - AS398431415  0.1% 471.7 -- RATECOM-AS ZAO "Ratecom"
17 - AS48068 448  0.0% 448.0 -- VISONIC Visonic Ltd
18 - AS56886 440  0.0% 440.0 -- REDSTAR-AS OOO "Red Star"
19 - AS676   437  0.0% 437.0 -- United Nations Development 
Programme
20 - AS37296 432  0.0% 432.0 -- AFCOMSAT


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 148.164.14.0/24   20430  1.2%   AS23154 -- SANMINA-SCI Sanmina-SCI 
Corporation
 2 - 84.204.132.0/24   15228  0.9%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 217.170.24.0/21   11373  0.7%   AS29126 -- DATIQ-AS Datiq B.V.
 4 - 130.36.34.0/2411372  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 130.36.35.0/2411372  0.7%   AS32528 -- ABBOTT Abbot Labs
 6 - 122.161.0.0/1610381  0.6%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 7 - 62.36.252.0/22 8257  0.5%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 202.92.235.0/248179  0.5%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 190.67.172.0/226746  0.4%   AS3816  -- COLOMBIA TELECOMUNICACIONES 
S.A. ESP
10 - 62.36.249.0/24 6209  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
11 - 204.29.239.0/246186  0.4%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
12 - 150.225.0.0/16 6186  0.4%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
13 - 62.36.241.0/24 5685  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
14 - 62.36.210.0/24 5463  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 194.63.9.0/24  5322  0.3%   AS1273  -- CW Cable and Wireless Worldwide 
plc
16 - 41.43.219.0/24 4202  0.2%   AS8452  -- TE-AS TE-AS
17 - 41.43.222.0/24 4150  0.2%   AS8452  -- TE-AS TE-AS
18 - 205.73.118.0/24

The Cidr Report

[cidr-report]

This report has been generated at Fri Feb 10 21:12:37 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
03-02-12397625  230154
04-02-12398129  229956
05-02-12397792  230223
06-02-12397996  230469
07-02-12398139  230795
08-02-12398862  230787
09-02-12399071  230735
10-02-12398957  231557


AS Summary
 40190  Number of ASes in routing system
 16851  Number of ASes announcing only one prefix
  3442  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  109981184  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 10Feb12 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 399616   231551   16806542.1%   All ASes

AS6389  3442  204 323894.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS7029  3432 1743 168949.2%   WINDSTREAM - Windstream
   Communications Inc
AS18566 2093  413 168080.3%   COVAD - Covad Communications
   Co.
AS4766  2475 1002 147359.5%   KIXS-AS-KR Korea Telecom
AS22773 1510  118 139292.2%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS2118  1385   14 137199.0%   RELCOM-AS OOO "NPO Relcom"
AS4323  1611  387 122476.0%   TWTC - tw telecom holdings,
   inc.
AS28573 1659  497 116270.0%   NET Servicos de Comunicao S.A.
AS4755  1531  402 112973.7%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS1785  1871  791 108057.7%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS7552  1393  358 103574.3%   VIETEL-AS-AP Vietel
   Corporation
AS10620 1751  739 101257.8%   Telmex Colombia S.A.
AS19262 1386  397  98971.4%   VZGNI-TRANSIT - Verizon Online
   LLC
AS7303  1263  371  89270.6%   Telecom Argentina S.A.
AS26615  897   33  86496.3%   Tim Celular S.A.
AS8402  1645  824  82149.9%   CORBINA-AS OJSC "Vimpelcom"
AS4808  1149  342  80770.2%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS8151  1477  675  80254.3%   Uninet S.A. de C.V.
AS18101  952  156  79683.6%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS24560 1014  329  68567.6%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS9498   885  204  68176.9%   BBIL-AP BHARTI Airtel Ltd.
AS9394   882  207  67576.5%   CRNET CHINA RAILWAY
   Internet(CRNET)
AS7545  1643  979  66440.4%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS3356  1096  455  64158.5%   LEVEL3 Level 3 Communications
AS30036 1384  761  62345.0%   MEDIACOM-ENTERPRISE-BUSINESS -
   Mediacom Communications Corp
AS17974 1728 1119  60935.2%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS17676  681   75  60689.0%   GIGAINFRA Softbank BB Corp.
AS15557 1095  510  58553.4%   LDCOMNET Societe Francaise du
   Radiotelephone S.A
AS4804   660   95  56585.6%   MPX-AS Microplex PTY LTD
AS3549   986  430  55656.4%   GBLX Global Crossing Ltd.

Total  44976146303034667.5%   Top 30 total


Possible Bogus Routes

10.86.64.32/30   AS6

Re: Dear RIPE: Please don't encourage phishing

[Måns Nilsson]

On Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
> > So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.

Web site? With the RIPE db one communicates using PGP email for data
in and port 43 queries for data out. The web site is for signing up to
RIPE meetings. Yes, RIPE NCC, I think that you put a lot of resources into
new fancy guish junk, and tend to forget how things should be done, and
some things -- the horror! -- are only possible to accomplish using the
web site and some forgotten password. To me, that is much more annoying
than the side projects that people are griping over.


 
> wy to much phishing, and it is getting subtle and good.

Indeed. 

-- 
Måns

Re: Dear RIPE: Please don't encourage phishing

[Rich Kulawiec]

On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
> Remind me again why we live in this sad word Randy (correcly) described?

Because banks and many other institutions have prioritized all-singing,
all-dancing, bloated, horribly-badly-marked-up HTML email with
"stationary" and logos and pictures and web bugs far, FAR ahead of
security, privacy, accessability, portability and other -ilities that
I'm too lazy to enumerate just now.  Besides: it's not like it's *their*
accounts that will get hosed or *their* money that will get lost.
Things like that only happen to the little people.

See also this related note:

http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html

---rsk

Re: Dear RIPE: Please don't encourage phishing

[Brandon Butterworth]

> So it's necessary to throw the baby out with the bathwater, and tell them
> never to click on a link...

That baby was ugly anyway

brandon

Re: Dear RIPE: Please don't encourage phishing

[Jeff Kell]

There used to be the old programming benchmark of how large a "program"
(in lines, as well as compiled bytes) it took to say "Hello, world."

The 21st century benchmark might now well be the size of a "Hello,
world" e-mail.

Or a web page with a similar statement.

Jeff

On 2/10/2012 6:46 PM, Rich Kulawiec wrote:
> On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
>> Remind me again why we live in this sad word Randy (correcly) described?
> Because banks and many other institutions have prioritized all-singing,
> all-dancing, bloated, horribly-badly-marked-up HTML email with
> "stationary" and logos and pictures and web bugs far, FAR ahead of
> security, privacy, accessability, portability and other -ilities that
> I'm too lazy to enumerate just now.  Besides: it's not like it's *their*
> accounts that will get hosed or *their* money that will get lost.
> Things like that only happen to the little people.
>
> See also this related note:
>
>   http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html
>
> ---rsk
>

Re: couple of questions regarding 'lifeline' and large scale nat...

[Masataka Ohta]

Leo Bicknell wrote:

> UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
> passthrough), combined with the problems of some applications that
> make thousands of TCP connections in a short order eating up ports
> makes it a nightmare to manage and debug.

The applications can simply be debugged to use socket option
of REUSEPORT.

I pointed it out so along with static port mapping at the last
meeting in "Track: IPv4 runout, Doing More with Less".

> Of course, if they are
> doing illegal things you'd better keep some detailed records of who did
> what when a LEO comes knocking.

Are you saying we MUST record all the IP addresses and
port numbers of all peers of your customers to prevent
illegal things?

If so, we have to do so, even if you are not using NAT,
I'm afraid.

If not and we only have to have information on which
port is used by which customer, static port mapping
is just fine.

Anyway, developers of virus software will be quite
cooperative to use REUSEPORT, to hide symptoms that
the virus software is installed.

> The key to a low cost service is making it as low cost as possible,
> moving the NAT inside the carrier will had a huge amount of headache and
> support costs, not what you want.

Use NAT with static port mapping (and same port numbers are used
in and out), there is no headache and support cost caused by NAT.

> A possibly relevant question with IPv4 exhaustion coming is could you
> make this service IPv6 only so you don't have to find IPv4 addresses for
> it.

IPv6 means considerably more amount of headache and
support costs than using NAT cleverly and simply.

Masataka Ohta

Re: Dear RIPE: Please don't encourage phishing

[Landon Stewart]

On 10 February 2012 16:09, Brandon Butterworth  wrote:

> > So it's necessary to throw the baby out with the bathwater, and tell them
> > never to click on a link...
>
> That baby was ugly anyway
>
>
HAHAHA.

My $0.02 on this issue is if the message is rich text I hover over the link
and see where it actually sends me.  If I don't know what that link is then
I don't click it.  Not sure how long it's going to take, probably a
generation, for people to use some sense before mindlessly clicking on
stuff.

Banks and businesses that keep sensitive information in a protected area on
the web for you should start sending messages in PLAIN TEXT so you have to
copy/paste the link if you don't already have it book marked or don't want
to type it.  Sure it's not all flashy and there's no nice pictures and junk
but if you get an email from your bank that's not in plain text and
contains hyperlinks then you'll know it's fake before you even read it.

---
Landon Stewart >
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net

Re: Dear RIPE: Please don't encourage phishing

[Randy Bush]

> My $0.02 on this issue is if the message is rich text I hover over the link
> and see where it actually sends me.

idn has made this unsafe

randy

Re: couple of questions regarding 'lifeline' and large scale nat...

[Leo Bicknell]

In a message written on Sat, Feb 11, 2012 at 09:19:46AM +0900, Masataka Ohta 
wrote:
> The applications can simply be debugged to use socket option
> of REUSEPORT.

"Simple" is subjective.  Keep in mind many users will have a home
gateway which also does NAT.  And indeed double NAT in the home (router
doing NAT, third party device doing NAT) is depressingly common.  That
means some of the troubleshooting will be via a triple-NAT if the
carrier is performing the conversion.

> Are you saying we MUST record all the IP addresses and
> port numbers of all peers of your customers to prevent
> illegal things?

If the carrier NAT's, maybe.

Today port information need not be stored, because an IP is assigned
to a customer.  Law enforcement can come request who was using an
IP, and be given the customer information.  It's what everyone has
come to expect.

It's also not just what is legally required, but what is administratively
friendly.  Will the law say you have to track ports with carrier
grade NAT, probably not.  Will law enforcement spend a lot more
time with your staff trying to track down bad people costing you
time and money if you don't, probably.

Large operations tend to find that having a cost effective and staff
time effective way to deal with law enforcement is very important.

> IPv6 means considerably more amount of headache and
> support costs than using NAT cleverly and simply.

When IPv4 addresses are selling for $100 an address that equation
changes quickly.  That day may be only a few months or years off.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpyXfHZbZKQQ.pgp
Description: PGP signature

Re: Dear RIPE: Please don't encourage phishing

[Masataka Ohta]

Randy Bush wrote:

>> My $0.02 on this issue is if the message is rich text I hover over the link
>> and see where it actually sends me.
> 
> idn has made this unsafe

I pointed it out at IETF Munich in 1997 that with an example of:

MICROSOFT.COM

where 'C' of MICROSOFT is actually a Cyrillic character.

But, people insisted working on useless IDN.

Masataka Ohta

Re: Dear RIPE: Please don't encourage phishing

[Adrian]

On Friday 10 February 2012 17:24, Landon Stewart wrote:
> My $0.02 on this issue is if the message is rich text I hover over the link
> and see where it actually sends me.  If I don't know what that link is then
> I don't click it.


Oh really? How about trying this Go to Google and search "is my url safe":
http://www.google.com/search?q=is+my+url+safe

Now hover over that second link reportedly to faq.ssl.com and look at what 
your browser reports:
http://faq.ssl.com/article.aspx?id=10068

Now look at the page code or copy/paste the URL somewhere else... Where does 
that link really go?

http://www.google.com/url?q=http://faq.ssl.com/article.aspx%3Fid%3D10068&sa=U&ei=JcI1T_DRKJDXiAKauoSvCg&ved=0CBgQFjAB&usg=AFQjCNHSmrhtgWQczEe1j0LhdMdUW5x4LA

So much for looking at what mouse-over shows


Adrian

Re: couple of questions regarding 'lifeline' and large scale nat...

[Joe Hamelin]

On Fri, Feb 10, 2012 at 1:19 PM, Eric J Esslinger wrote:

> We're toying with the idea of a low bitrate 'lifeline' internet on our
> cable system, maybe even bundled with a certain level of cable service.
>
> First question, if you happen to be doing something like this, what bit
> rates are you providing.
>

Well, a lifeline telephone is effectively 64kb/s, up and down.  Makes me
remember when I had my first ISDN line and was happy to get beyond dial-up
rates.


> Second question, though 'real' internet customers all get real IP's, what
> would you think of doing something like this with 'large scale' nat
> instead. Understand, we're only talking about basic internet, something
> like a 256k/96k (or similar) connect, not something that would be used by a
> serious user. (One thing we are looking at is some older dial up users we
> still have, most of which could go onto cable just fine but don't want to
> pay the price).
>

Force SMTP to something sane, block all the 139, etc. MS ports.  Basic web,
telnet, and ssh.  Set it up like a coffee house.  Use a proxy and make them
register.  It's not like they are chatting 911, ya know.  If they have NAT
issues, then they need a real account.  If they can get to google,
wikimedia, or what ever a high school student needs to research papers,
then they have what they need for a life-line.  Let chat protocols through,
that's low bandwidth.  I'm guessing that this is done as a favor to the
customer that won't/can't pay for a real account.  But let them know it's
not a real account.  This is just to give them a taste of real IP and not a
solution to all their problems.  Shove them a NATted DHCP address and if
they can't figure that out then refer them to the local wizkid or a better
plan with support.  Let them know up front that this is a basic service and
don't expect phone support.  If you're a cable company then they can call
and say the cable is out.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: Dear RIPE: Please don't encourage phishing

[Valdis . Kletnieks]

On Fri, 10 Feb 2012 16:24:11 PST, Landon Stewart said:
> I don't click it.  Not sure how long it's going to take, probably a
> generation, for people to use some sense before mindlessly clicking on
> stuff.

Only if you find a way to keep more idiots from being born. :)

I don't think anybody wants to go there.  At least not on this list.


pgpU0oDEN1whk.pgp
Description: PGP signature

RE: Dear RIPE: Please don't encourage phishing

[Vinny_Abello]

Unfortunately that's not under control of those businesses. This plain text 
email you sent comes across with clickable mailto and http links in your 
signature in most modern email clients despite you having sent it in plain 
text. "Helpful" email program defaults won't force people to copy and paste the 
URL. They just create the hyperlink for people based on the pattern in the 
plain text message. It seems anything beginning with www or http(s):// will be 
converted to a clickable link out of convenience to the user. It's always that 
endless struggle of security vs. convenience...

-Vinny

-Original Message-
From: Landon Stewart [mailto:lstew...@superb.net] 
Sent: Friday, February 10, 2012 7:24 PM
To: Brandon Butterworth
Cc: nanog@nanog.org
Subject: Re: Dear RIPE: Please don't encourage phishing

On 10 February 2012 16:09, Brandon Butterworth  wrote:

> > So it's necessary to throw the baby out with the bathwater, and tell them
> > never to click on a link...
>
> That baby was ugly anyway
>
>
HAHAHA.

My $0.02 on this issue is if the message is rich text I hover over the link
and see where it actually sends me.  If I don't know what that link is then
I don't click it.  Not sure how long it's going to take, probably a
generation, for people to use some sense before mindlessly clicking on
stuff.

Banks and businesses that keep sensitive information in a protected area on
the web for you should start sending messages in PLAIN TEXT so you have to
copy/paste the link if you don't already have it book marked or don't want
to type it.  Sure it's not all flashy and there's no nice pictures and junk
but if you get an email from your bank that's not in plain text and
contains hyperlinks then you'll know it's fake before you even read it.

---
Landon Stewart >
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net

Re: couple of questions regarding 'lifeline' and large scale nat...

[Carlos Alcantar]

You might also want to think about it's not to far off that the gov starts
supplementing those cost of these users, with all the changes being made
in USF.  Possible why comcast has started taking on these users to get a
good head count.  Does anyone know with these low end comcast package does
the user still need to pay the $5 modem rental fee?

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / car...@race.com / http://www.race.com





-Original Message-
From: Eric J Esslinger 
Date: Fri, 10 Feb 2012 15:19:24 -0600
To: "nanog@nanog.org" 
Subject: couple of questions regarding 'lifeline' and large scale nat...

We're toying with the idea of a low bitrate 'lifeline' internet on our
cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit
rates are you providing.
Second question, though 'real' internet customers all get real IP's, what
would you think of doing something like this with 'large scale' nat
instead. Understand, we're only talking about basic internet, something
like a 256k/96k (or similar) connect, not something that would be used by
a serious user. (One thing we are looking at is some older dial up users
we still have, most of which could go onto cable just fine but don't want
to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand
customers for this. We're not a large ISP/cable company by any means.

__
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and
is intended for the person/entity to whom it was originally addressed. Any
use by others is strictly prohibited.


smime.p7s
Description: S/MIME cryptographic signature