Re: P2P link over STM-1

[Per Carlson]

If it's a full STM-1, your client might be thinking of POS (packet over
sonet/sdh). This is (were) a very common high bandwidth technology some
years ago.

At least the 7200 do have cheap POS interfaces.
-- 
Pelle
(sorry about the top-posting, I'm  on a mobile device)

Yahoo! security contact needed

[Mike]

Greetings,

   I need to get a hold of Yahoo! security and the online submission 
form doesn't seem to work for me. Anyone got a good contact?


Thank you.

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Ben McGinnes]

On 8/10/10 10:00 AM, Leen Besselink wrote:
> 
> k...@domain.tld for when you have a personal domain
> key-u...@domain.tld for when you have a server which understand address
> extensions

Actually I think it's user+...@domain.tld for the second one.  At least
that's what I've seen for Postfix.  Not so sure about other MTAs.


Regards,
Ben



signature.asc
Description: OpenPGP digital signature

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Leen Besselink]

On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote:
> you just give contacts for the passwords with which you have received
> a new one.
>

Hi Sven/others,

This very much sounds like TMDA:

http://tmda.net/
http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent

Where by each person that needs to contact you, you give a unique e-mail
address.

So you give out k...@domain.tld to user1 and k...@domain.tld to user2.
That way when you registered at that webshop or mailinglist
and that e-mail address gets used for spam, you just delete that one
unique key (and maybe, if you still want to communicate with them,
a new unique key).

There are 2 variants if I remember correctly:

k...@domain.tld for when you have a personal domain
key-u...@domain.tld for when you have a server which understand address
extensions

While there is software for that, I've been doing something similair to
this by hand for a long time for a lot of contacts.

The good thing about using a unique e-mail address instead of a password
is that you can block at the SMTP-level, without even receiving an
e-mail body.

Have a nice day,
Leen.

> each potential person that can send email to your email address, gets
> a unique password from you.
>
> sending person/maillist 1 gets password abcdefg to send to
> b...@example.com (no matter from which email address)
>
> sending person/maillist 2 gets password 123545 to send to
> b...@example.com (no matter from which email address)
>
> email clients should be modified to include the password: field both
> in the email itself and in the header entry field (to: from: subjecT:
> or just store them together with the destination address in the
> address book
>
> mailservers (the maildrop part) should be modified to parse the
> Password: header, compare it to the list of currently allowed
> passwords for the destination email address and then either drop to
> the mailbox, or bounce. (we did this in our test setup by simply
> parsing the entire email, so the password could be -anywhere- in the
> email :P
>
> ofcourse the Password: line should be only sent to the recipient, not
> to other Cc: or Bcc: target addresses of the same email, the first
> stmp server in the chain should solve this bit.
>
> actually, durign our tests, we turned off all the header
> verifications, RBL's, etc on our smtpds, and the only spam that got
> through were emails that accidentially contained the password string
> in a binary attachment (as we parsed the entire email .. we should not
> do that, just teh Password: line  in the final version :P and stuff
> where we gave, for example, nanog, the password "nanog" and then nanog
> is cc'ed in a spam
> both of which cases can be solved with the standardization of the
> Password: field
>
> once this is in place, all smtpds can go open relay again, port 25 can
> be opened again on eyeball networks, RBLs and graylisting can remain
> at home, and the SMTP email system will be 100% spam free and reliable
> and real-time. (there are several other features which have been
> removed from most smtpds to "stop spam" such as accepting ip addresses
> rather than domain names in the target email address, which can then
> return)
>
> all the other stuff never stopped spam, it just made smtp email
> unreliable slow and no longer an option for 99% of the things where
> email was used for before, and skype, msn and facebook are used for
> today.
>
> this system -does- stop spam, but the disadvantage to this system is
> that by implementing it, smtp email is no longer suitable for "initial
> contact"
>
> (well you could ofcourse place passwords in whois and on your website
> for your hostmaster/sales box so random people can still make initial
> contact over smtp, or simply accept all passwords on those boxes, on
> which then there WILL be spam.. ;)
>
> i'd say, smtp no longer being "open for any random idiot to mail any
> other random idiot without knowing each other first" is less of a
> disadvantage than taking the whole thing slowly die by making it less
> and less attractive as a means of communications (slow, unreliable and
> not real-time, and still with spam coming in by the 1000s, which it is
> due to "conventional" attempts to stop spam)
>
>

Re: Facebook down!! Alert!

[Jeff Harper]

- Original Message -
> From: "Bret Clark" 
> I've always looked at the nanog list representing issues up to layer 4
> of the OSI model; mostly layer 3/4. Maybe a new mailing list could be
> made called the North American Network Applications Group
> (nanag)...there might be a pun there :).

Perhaps, but Facebook being down is usually a "Layer 8" issue.  (Layer 8 being 
the Human involved ;)

RE: P2P link over STM-1

[Michael K. Smith - Adhost]

> -Original Message-
> From: Peter Rudasingwa [mailto:peter.rudasin...@altechstream.rw]
> Sent: Thursday, October 07, 2010 1:24 AM
> To: nanog@nanog.org
> Subject: P2P link over STM-1
> 
> I have clients who want a P2P link over STM-1.
> 
> How can I achieve this? What kind of equipment do I need.
> 
> At the moment I have a cisco 6500 and 7200VXR
> 
> Thanks,
> 
> Peter R.

AFAIK you can get a channelized STM-1 card and offer your customers
E-1's, etc.  Or, if you are looking to do Ethernet you would have to
move into the 15454 type chassis.

Mike

Re: P2P link over STM-1

[Carlos Martinez-Cagnazzo]

As said above, STM-1s are by their very nature point to point links.

You just need an STM-1 interface on your side and another on the customer
side. Which one will depend on the router models you will be using. Also, as
said above, you will need to engage the help of your local Cisco partner for
this.

>From your side (I mean the service provider side) you can also have a
channelized STM-4 or STM-16 and use one STM-1 channel for this. This would
be a good idea if you plan to have more than one customer of this nature.
Beware that these interfaces can be quite expensive.

Hope this helps,

Carlos

On Thu, Oct 7, 2010 at 4:24 AM, Peter Rudasingwa <
peter.rudasin...@altechstream.rw> wrote:

> I have clients who want a P2P link over STM-1.
>
> How can I achieve this? What kind of equipment do I need.
>
> At the moment I have a cisco 6500 and 7200VXR
>
> Thanks,
>
> Peter R.
>



-- 
--
=
Carlos M. Martinez-Cagnazzo
http://cagnazzo.name
=

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Sven Olaf Kamphuis]

When was email *ever* expected to be real-time?  If you need real time, use IM (the clue 
is in the "I"), or pick up the phone.


if you simply run the smtpd on port 25 of the little boxy thing with the 
blinking lights and the big shiney apple on it on your 
desk (which has for most applications replaced the big dusty mainframe in 
the basement to which your (real-time interactive!) terminal on your desk 
connected.. and give it a "real" ip, its pretty much real time.


and that's how it was meant to be used, yet made impossible by those dusty 
old self-declared 'spam fighters', with their clearly non working methods.

Re: reachability problems Europe->US?

[Richard A Steenbergen]

On Thu, Oct 07, 2010 at 07:12:33PM +0200, Thomas Schmid wrote:
> yes, I can confirm that situation is back to normal now after we 
> re-enabled the GBLX session. I heared from others that it was again a 
> broken LSP problem in GBLX (unconfirmed :) )

Global Crossing recently started deploying Foundry/Brocade XMR's in 
their MPLS core, as a lower cost alternative to their old T640/OC192 
MPLS core model. Unfortunately these boxes are buggy as all hell, and 
seem to blackhole LSPs somewhere in their network on at least a weekly 
basis. I think we've seen at least a dozen issues similar to this over 
the last couple months, though most of them were out of LA, so I didn't 
know they had actually done a Seattle deployment.

Honestly GX deserves what they get on this one. I'm not aware of any 
other large network who has ever done a serious MPLS deployment using 
these boxes (and if you're thinking of replying to this and saying "hey 
we do some vll's between 2 routers and it seems to work", stop and think 
about what I might mean when I say a SERIOUS mpls deployment first :P), 
so this was pretty much to be expected. I'll also say that I'm 
remarkably underwhelmed by their response to this issue, and suggest 
that anyone who doesn't want their packets blackholed by the Floundrys 
be prepared to vote with their wallet.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

RE: P2P link over STM-1

[Welch, Bryan]

I politely suggest a call into your Cisco account team so they can help you 
spec the equipment you require.  Otherwise a quick google for Cisco+OC-48 would 
help you out tremendously.



Bryan

-Original Message-
From: Peter Rudasingwa [mailto:peter.rudasin...@altechstream.rw] 
Sent: Thursday, October 07, 2010 1:24 AM
To: nanog@nanog.org
Subject: P2P link over STM-1

I have clients who want a P2P link over STM-1.

How can I achieve this? What kind of equipment do I need.

At the moment I have a cisco 6500 and 7200VXR

Thanks,

Peter R.

Re: reachability problems Europe->US?

[Thomas Schmid]

Am 07.10.2010 18:46, schrieb John van Oppen:

It looked like a broken aggregated Ethernet bundle or something similar... 
Most annoying was that the issue moved around a bit, over about five hours all 
the broken test IPs we had started working again and then other destinations 
started failing.All was well when we turned down gblx. As of now though 
we are seeing the issue as fixed and turned up GBLX again.



yes, I can confirm that situation is back to normal now after we re-enabled
the GBLX session. I heared from others that it was again a broken LSP
problem in GBLX (unconfirmed :) )

Cheers,

  Thomas



smime.p7s
Description: S/MIME Cryptographic Signature

RE: reachability problems Europe->US?

[John van Oppen]

It looked like a broken aggregated Ethernet bundle or something similar... 
Most annoying was that the issue moved around a bit, over about five hours all 
the broken test IPs we had started working again and then other destinations 
started failing.All was well when we turned down gblx. As of now though 
we are seeing the issue as fixed and turned up GBLX again.

Thanks,
John
-Original Message-
From: Heath Jones [mailto:hj1...@gmail.com] 
Sent: Thursday, October 07, 2010 9:22 AM
To: John van Oppen
Cc: Thomas Schmid; nanog@nanog.org
Subject: Re: reachability problems Europe->US?

>... random traffic (into) their network via our transit link gets black-holed.
So for the same source & destination, sometimes it works, sometimes it doesn't?

RE: reachability problems Europe->US?

[John van Oppen]

I know for certain it was gblx, noc confirmed, we saw this to multiple 
destinations all with the outbound towards gblx (not just DFN).   We are on the 
same GBLX pop the sites they are talking about are connected to (westin) and 
almost every path I see back to dfn (from seven upstreams in seattle) was via 
gblx not qwest, the only exceptions were level3's and Savvis' routes which are 
via AS1299.

I think the asymmetric routing was obfuscating the problem a bit for the guys 
attached to DFN.

John

-Original Message-
From: Heath Jones [mailto:hj1...@gmail.com] 
Sent: Thursday, October 07, 2010 9:24 AM
To: John van Oppen
Cc: Thomas Schmid; nanog@nanog.org
Subject: Re: reachability problems Europe->US?

It seemed from the symptoms OP was seeing, that Qwest was the issue.
Has GLBX reported to you that they are having a fault? If not, perhaps
try tagging your exported routes to GLBX with 8010 as per this:
http://onesc.net/communities/as3549/



On 7 October 2010 16:59, John van Oppen  wrote:
> Global crossing is having major issues (since yesterday actually) in Seattle. 
>    Every path I see to dfn.de is via gblx and Microsoft hosts most of those 
> sites out of the seattle area so they may be seeing the same issue.
>
> Based on what we can see gblx has a broken port-channel or something similar 
> here as random traffic (into) their network via our transit link gets 
> black-holed.   We could not even reach global crossing's own name servers for 
> a while.    We gave up and turned down BGP yesterday until we hear from them. 
>   Based on graphs at the time things broke they appeared to be black-holing 
> roughly 1/4 of what we were sending them.
>
>
> Thanks,
> John van Oppen
> Spectrum Networks / AS 11404
>
>
> -Original Message-
> From: Thomas Schmid [mailto:sch...@dfn.de]
> Sent: Thursday, October 07, 2010 6:10 AM
> To: Heath Jones
> Cc: nanog@nanog.org
> Subject: Re: reachability problems Europe->US?
>
> Hi,
>
> On 07.10.2010 14:35, Heath Jones wrote:
>>> Seems to be only source-prefix-based, but several ISPs in europe are 
>>> affected.
>> Can you post source and destination IP's ?
>
> source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21,
> destination: 65.122.178.73, 63.228.223.104
>
> traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets
>  1  er-rz-gig-3-3.stw-bonn.de (131.220.99.62)  1.792 ms  1.275 ms  1.125 ms
>  2  xr-bon1-te2-3.x-win.dfn.de (188.1.233.193)  0.705 ms  2.132 ms  0.755 ms
>  3  xr-bir1-te2-3.x-win.dfn.de (188.1.144.9)  1.477 ms  1.936 ms  1.051 ms
>  4  zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46)  4.034 ms  3.734 ms  4.957 
> ms
>  5  64.213.78.237 (64.213.78.237)  3.866 ms  3.295 ms  26.854 ms
>  6  jfk-brdr-04.inet.qwest.net (63.146.26.225)  119.511 ms  92.735 ms  99.019 
> ms
>  7  * * *
>
> or quote from DE-CIX tech-list:
>
> [www.microsoft.com]
> ---
> We also have some connectivity problems to ms, changing the bgp routing to
> another tier 1 carrier don t resolve the problem
> ---
>
> Cheers,
>
>  Thomas
>
>

Re: reachability problems Europe->US?

[Heath Jones]

It seemed from the symptoms OP was seeing, that Qwest was the issue.
Has GLBX reported to you that they are having a fault? If not, perhaps
try tagging your exported routes to GLBX with 8010 as per this:
http://onesc.net/communities/as3549/



On 7 October 2010 16:59, John van Oppen  wrote:
> Global crossing is having major issues (since yesterday actually) in Seattle. 
>    Every path I see to dfn.de is via gblx and Microsoft hosts most of those 
> sites out of the seattle area so they may be seeing the same issue.
>
> Based on what we can see gblx has a broken port-channel or something similar 
> here as random traffic (into) their network via our transit link gets 
> black-holed.   We could not even reach global crossing's own name servers for 
> a while.    We gave up and turned down BGP yesterday until we hear from them. 
>   Based on graphs at the time things broke they appeared to be black-holing 
> roughly 1/4 of what we were sending them.
>
>
> Thanks,
> John van Oppen
> Spectrum Networks / AS 11404
>
>
> -Original Message-
> From: Thomas Schmid [mailto:sch...@dfn.de]
> Sent: Thursday, October 07, 2010 6:10 AM
> To: Heath Jones
> Cc: nanog@nanog.org
> Subject: Re: reachability problems Europe->US?
>
> Hi,
>
> On 07.10.2010 14:35, Heath Jones wrote:
>>> Seems to be only source-prefix-based, but several ISPs in europe are 
>>> affected.
>> Can you post source and destination IP's ?
>
> source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21,
> destination: 65.122.178.73, 63.228.223.104
>
> traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets
>  1  er-rz-gig-3-3.stw-bonn.de (131.220.99.62)  1.792 ms  1.275 ms  1.125 ms
>  2  xr-bon1-te2-3.x-win.dfn.de (188.1.233.193)  0.705 ms  2.132 ms  0.755 ms
>  3  xr-bir1-te2-3.x-win.dfn.de (188.1.144.9)  1.477 ms  1.936 ms  1.051 ms
>  4  zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46)  4.034 ms  3.734 ms  4.957 
> ms
>  5  64.213.78.237 (64.213.78.237)  3.866 ms  3.295 ms  26.854 ms
>  6  jfk-brdr-04.inet.qwest.net (63.146.26.225)  119.511 ms  92.735 ms  99.019 
> ms
>  7  * * *
>
> or quote from DE-CIX tech-list:
>
> [www.microsoft.com]
> ---
> We also have some connectivity problems to ms, changing the bgp routing to
> another tier 1 carrier don t resolve the problem
> ---
>
> Cheers,
>
>  Thomas
>
>

Amazon - Flexible Payments Service (Amazon FPS)

[Ryan Finnesey]

Would someone from Amazon mind contacting me off-list.  I have some
questions on the best way to pass traffic to Flexible Payments Service
(Amazon FPS) and my e-mails to the contacts within peeringdb.com have
gone unanswered.

Cheers
Ryan

Re: reachability problems Europe->US?

[Heath Jones]

>... random traffic (into) their network via our transit link gets black-holed.
So for the same source & destination, sometimes it works, sometimes it doesn't?

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Tim Franklin]

> If i have to wait for 20 minutes for an email, i've started skype 
> already.. You know what, why don't we simply turn the smtp servers
> -off- and use skype and msn for everything... saves electricity :P

By that argument, why don't we turn off the Internet and use SMS for everything?

> It may be a bit too late to fix the protocol itself to be real-time
> and peer-to-peer again, but this time without spam ofcourse, as the
> market has been flooded with better protocols already anyway (the
> problem with these however is that they're propriatory and vendor
> dependant).

When was email *ever* expected to be real-time?  If you need real time, use IM 
(the clue is in the "I"), or pick up the phone.

Part of the beauty of email is that it doesn't require all participants to be 
connected at the same time, and everyone can deal with it when it's convenient 
to *them*, not convenient to the sender.  Use the right communication tool for 
the right job.

I can remember email being batch-transferred over dial-up lines, hop-by-hop, 
and taking hours or even days to cross the globe - and I'm a long way from 
being an Internet "old-timer".

Regards,
Tim.

RE: reachability problems Europe->US?

[John van Oppen]

Global crossing is having major issues (since yesterday actually) in Seattle.   
 Every path I see to dfn.de is via gblx and Microsoft hosts most of those sites 
out of the seattle area so they may be seeing the same issue.

Based on what we can see gblx has a broken port-channel or something similar 
here as random traffic (into) their network via our transit link gets 
black-holed.   We could not even reach global crossing's own name servers for a 
while.We gave up and turned down BGP yesterday until we hear from them.   
Based on graphs at the time things broke they appeared to be black-holing 
roughly 1/4 of what we were sending them.


Thanks,
John van Oppen
Spectrum Networks / AS 11404


-Original Message-
From: Thomas Schmid [mailto:sch...@dfn.de] 
Sent: Thursday, October 07, 2010 6:10 AM
To: Heath Jones
Cc: nanog@nanog.org
Subject: Re: reachability problems Europe->US?

Hi,

On 07.10.2010 14:35, Heath Jones wrote:
>> Seems to be only source-prefix-based, but several ISPs in europe are 
>> affected.
> Can you post source and destination IP's ?

source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21,
destination: 65.122.178.73, 63.228.223.104

traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets
  1  er-rz-gig-3-3.stw-bonn.de (131.220.99.62)  1.792 ms  1.275 ms  1.125 ms
  2  xr-bon1-te2-3.x-win.dfn.de (188.1.233.193)  0.705 ms  2.132 ms  0.755 ms
  3  xr-bir1-te2-3.x-win.dfn.de (188.1.144.9)  1.477 ms  1.936 ms  1.051 ms
  4  zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46)  4.034 ms  3.734 ms  4.957 ms
  5  64.213.78.237 (64.213.78.237)  3.866 ms  3.295 ms  26.854 ms
  6  jfk-brdr-04.inet.qwest.net (63.146.26.225)  119.511 ms  92.735 ms  99.019 
ms
  7  * * *

or quote from DE-CIX tech-list:

[www.microsoft.com]
---
We also have some connectivity problems to ms, changing the bgp routing to
another tier 1 carrier don t resolve the problem
---

Cheers,

  Thomas

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Nick Hilliard]

On 07/10/2010 13:10, Sven Olaf Kamphuis wrote:

You know what, why don't we simply turn the smtp servers -off-


This is an excellent idea.  I invite you to do everyone a favour and turn 
yours off first.


Nick

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Valdis . Kletnieks]

On Thu, 07 Oct 2010 14:16:00 -, Sven Olaf Kamphuis said:
> you just give contacts for the passwords with which you have received a 
> new one.
> 
> each potential person that can send email to your email address, gets a 
> unique password from you.

You missed the point.  How does perso...@gmail.com ask me for a password, if
I don't accept his e-mail without one? (Hold this thought, we'll be back to 
this)

> sending person/maillist 1 gets password abcdefg to send to b...@example.com 
> (no matter from which email address)
> 
> sending person/maillist 2 gets password 123545 to send to b...@example.com 
> (no matter from which email address)

And if I've assigned 123545 to duct-tape-2...@yahoo.com, but he's since moved
to clawhammer...@gmail.com, how do I securely notify him of the new password,
keeping in mind that I'm probably changing the password *because the enemy
already has access to the old password*? "Hey Joe - somebody has enough access
to your system to get 123545 - so use fuzzy-wombat instead".  What's wrong with
this picture?

With 140 million compromised boxes where sending the new password is basically
e-mailing to the enemy, and the scheme leaking new passwords to boot, "revoke 
and
issue a new credential" simply doesn't scale.

In other words, the only sane response is "revoke and don't bother setting new
one". At which point the person has to contact me and ask for a new password.
"Hey, this is duct-tape-2010, my password doesn't work, give me a new one".
Given that his old password doesn't work because I revoked it when a spammer
got hold of it, how do I know that I'm not giving the new password directly to
the spammer and the esteemed Mr Tape has no idea any of this happened?

Further discussion probably belongs on SPAM-L.


pgpHmqWj6a3OQ.pgp
Description: PGP signature

Re: AS6517 - Reliance Globalcom -- routing three more hijacked blocks - bulk Whois

[John Curran]

On Oct 7, 2010, at 10:25 AM, Christopher Morrow wrote:
> 
> in stabbing around today on the ARIN online website I noticed this:
> 
> " ARIN provides access to a list of number resources in the database
> which have no valid POC data. A POC handle is marked invalid by ARIN
> staff when the POC has not been modified in more than one year and the
> POC fails to respond to ARIN's annual request to validate their POC
> information. In order to access this report, NRPM Policy 3.6.1
> requires that you meet the criteria specified in ARIN’s Bulk Whois
> policy, including signing an Acceptable Use Policy (AUP). Complete
> information on Bulk Whois, including the AUP and data request form can
> be found here. "
> 
> one wonders if this sort of thing could be useful to folks maintaining
> lists of numbers that are used to affect other folks business plans.

Chris - 
 
  Very timely...  I should advise the community that a revised ARIN
  Bulk WHOIS policy will be sent for community consultation shortly, 
  and folks should take a chance to comment on the valid uses of 
  access to this data.  More information on how ARIN processes 
  incoming suggestions and consultations is available here: 
  

FYI,
/John

John Curran
President and CEO
ARIN


  

Re: AS6517 - Reliance Globalcom -- routing three more hijacked blocks

[Sven Olaf Kamphuis]

On Thu, 7 Oct 2010, Heath Jones wrote:


Well, anyway, here's three more hijacked blocks that they (AS6517)
are routing.  This is in addition to the 75 such blocks I've already
reported.  (I guess that makes 78 hijacked blocks for them, in total.)


Out of curiosity, are you also reporting these blocks to Spamhaus?  I expect
their DROP list maintainers would be interested.


With an IP space of just 2^32, I'd suspect they are better off
maintaining a whitelist ;)



I'd say people that hijack space have a legitimate need for it or they 
would not be doing it. as long as spamming is not "criminal activity" i 
see no need to filter them actually, on the other hand, we spend a lot of 
time filtering MPAA/RIAA member ranges. I can has blacklist for those?

(those are the real enemies of the internet industry, not the spammers :P

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Sven Olaf Kamphuis]

you just give contacts for the passwords with which you have received a 
new one.


each potential person that can send email to your email address, gets a 
unique password from you.


sending person/maillist 1 gets password abcdefg to send to b...@example.com 
(no matter from which email address)


sending person/maillist 2 gets password 123545 to send to b...@example.com 
(no matter from which email address)


email clients should be modified to include the password: field both in 
the email itself and in the header entry field (to: from: subjecT: or just 
store them together with the destination address in the address book


mailservers (the maildrop part) should be modified to parse the Password: 
header, compare it to the list of currently allowed passwords for the 
destination email address and then either drop to the mailbox, or 
bounce. (we did this in our test setup by simply parsing the entire email, 
so the password could be -anywhere- in the email :P


ofcourse the Password: line should be only sent to the recipient, not to 
other Cc: or Bcc: target addresses of the same email, the first stmp 
server in the chain should solve this bit.


actually, durign our tests, we turned off all the header verifications, 
RBL's, etc on our smtpds, and the only spam that got through were emails 
that accidentially contained the password string in a binary attachment 
(as we parsed the entire email .. we should not do that, just teh 
Password: line  in the final version :P and stuff where we gave, for 
example, nanog, the password "nanog" and then nanog is cc'ed in a spam
both of which cases can be solved with the standardization of the 
Password: field


once this is in place, all smtpds can go open relay again, port 25 can be 
opened again on eyeball networks, RBLs and graylisting can remain at home, 
and the SMTP email system will be 100% spam free and reliable and 
real-time. (there are several other features which have been removed from 
most smtpds to "stop spam" such as accepting ip addresses rather than 
domain names in the target email address, which can then return)


all the other stuff never stopped spam, it just made smtp email unreliable 
slow and no longer an option for 99% of the things where email was used 
for before, and skype, msn and facebook are used for today.


this system -does- stop spam, but the disadvantage to this system is that 
by implementing it, smtp email is no longer suitable for "initial contact"


(well you could ofcourse place passwords in whois and on your website for 
your hostmaster/sales box so random people can still make initial contact 
over smtp, or simply accept all passwords on those boxes, on which then 
there WILL be spam.. ;)


i'd say, smtp no longer being "open for any random idiot to mail any other 
random idiot without knowing each other first" is less of a disadvantage 
than taking the whole thing slowly die by making it less and less 
attractive as a means of communications (slow, unreliable and not 
real-time, and still with spam coming in by the 1000s, which it is due to 
"conventional" attempts to stop spam)



--
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=
Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
 D-13359   Registration:HRA 42834 B
 BERLINPhone:   +31/(0)87-8747479
 Germany   GSM: +49/(0)152-26410799
RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
=
 C3P0, der elektrische Westerwelle

=

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Thu, 7 Oct 2010, valdis.kletni...@vt.edu wrote:


On Thu, 07 Oct 2010 12:10:37 -, Sven Olaf Kamphuis said:

If what you're asking under point c is "what happens if a system that
contains such a password for your email address gets compromised" the
answer is simple, you remove that specific password from your approved
passwords list


140 million or so compromised systems.  You may be spending a lot of time
removing compromised passwords from your list - and even more problematic,
notifying everybody of the *new* password(s) they should use to e-mail to you.
So far this month, I've seen 4,964 mails from 1,090 different From: lines
(mostly due to a subscription to the linux-kernel list, which is a true fire
hose), and some 250 different SMTP MAIL FROM: sources.


 (note that on the receiver side, the password is not 
linked
to the source emai

Re: AS6517 - Reliance Globalcom -- routing three more hijacked blocks

[Christopher Morrow]

On Thu, Oct 7, 2010 at 10:09 AM, Heath Jones  wrote:
>>> Well, anyway, here's three more hijacked blocks that they (AS6517)
>>> are routing.  This is in addition to the 75 such blocks I've already
>>> reported.  (I guess that makes 78 hijacked blocks for them, in total.)
>>
>> Out of curiosity, are you also reporting these blocks to Spamhaus?  I expect
>> their DROP list maintainers would be interested.
>
> With an IP space of just 2^32, I'd suspect they are better off
> maintaining a whitelist ;)

in stabbing around today on the ARIN online website I noticed this:

" ARIN provides access to a list of number resources in the database
which have no valid POC data. A POC handle is marked invalid by ARIN
staff when the POC has not been modified in more than one year and the
POC fails to respond to ARIN's annual request to validate their POC
information. In order to access this report, NRPM Policy 3.6.1
requires that you meet the criteria specified in ARIN’s Bulk Whois
policy, including signing an Acceptable Use Policy (AUP). Complete
information on Bulk Whois, including the AUP and data request form can
be found here. "

one wonders if this sort of thing could be useful to folks maintaining
lists of numbers that are used to affect other folks business plans.

[NANOG-announce] NANOG election results and other news

[Steve Feldman]

As usual for our October meetings, there has been a lot happening,
with more to come over the next few days.

Our annual election was held during NANOG 50, with these results:

   - Patrick Gilmore, Robert Seastrom, and Richard Steenbergen
 were elected to two-year terms on the NANOG SC (and also
 therefore to the NewNOG Board.)

   - The charter amendment to transition NANOG activities from Merit
 to NewNOG passed with 210 votes in favor, 16 votes against.

   - In the NewNOG election, the measure to adopt the Bylaws passed
 with 169 votes in favor, 26 against.

I have been elected by the SC to serve again as Chair for the coming
year, and Sylvie LaPerriere was elected as Vice-Chair.

The Program Committee selection process is underway, and the results
will be announced in the next day so.

Nominations are still open for Communications Committee positions.
I would like to encourage any of you who regularly participate in
the mailing list and are interested in maintaining list quality
and in building new forms of communication for the community to
consider volunteering.  Please see:

  http://www.nanog.org/governance/elections/2010elections/

for further information on the selection process.

For the Steering Committee,
Steve Feldman, chair

___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: AS6517 - Reliance Globalcom -- routing three more hijacked blocks

[Heath Jones]

>> Well, anyway, here's three more hijacked blocks that they (AS6517)
>> are routing.  This is in addition to the 75 such blocks I've already
>> reported.  (I guess that makes 78 hijacked blocks for them, in total.)
>
> Out of curiosity, are you also reporting these blocks to Spamhaus?  I expect
> their DROP list maintainers would be interested.

With an IP space of just 2^32, I'd suspect they are better off
maintaining a whitelist ;)

Re: reachability problems Europe->US?

[Heath Jones]

>>> Seems to be only source-prefix-based, but several ISPs in europe are
>>> affected.
> source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21,
> destination: 65.122.178.73, 63.228.223.104
> traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets
>  1  er-rz-gig-3-3.stw-bonn.de (131.220.99.62)  1.792 ms  1.275 ms  1.125 ms
>  2  xr-bon1-te2-3.x-win.dfn.de (188.1.233.193)  0.705 ms  2.132 ms  0.755 ms
>  3  xr-bir1-te2-3.x-win.dfn.de (188.1.144.9)  1.477 ms  1.936 ms  1.051 ms
>  4  zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46)  4.034 ms  3.734 ms  4.957
> ms
>  5  64.213.78.237 (64.213.78.237)  3.866 ms  3.295 ms  26.854 ms
>  6  jfk-brdr-04.inet.qwest.net (63.146.26.225)  119.511 ms  92.735 ms
>  99.019 ms

Based on all that, it looks like Qwest is not propogating your routes
within their network.
I was going to recommend route-views, but it might not reflect that
now if you have dropped GBLX.
Historical routing updates will show though if Qwest were advertising
reachability to you (which would be a good indicator if they were
filtering at their edge)

Re: AS6517 - Reliance Globalcom -- routing three more hijacked blocks

[Jason Bertoch]

On 2010/10/06 11:36 PM, Ronald F. Guilmette wrote:

Well, anyway, here's three more hijacked blocks that they (AS6517)
are routing.  This is in addition to the 75 such blocks I've already
reported.  (I guess that makes 78 hijacked blocks for them, in total.)


Out of curiosity, are you also reporting these blocks to Spamhaus?  I 
expect their DROP list maintainers would be interested.


--
/Jason



smime.p7s
Description: S/MIME Cryptographic Signature

Re: reachability problems Europe->US?

[Thomas Schmid]

an update:

On 07.10.2010 15:09, Thomas Schmid wrote:

Hi,

On 07.10.2010 14:35, Heath Jones wrote:

Seems to be only source-prefix-based, but several ISPs in europe are
affected.

Can you post source and destination IP's ?


source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21,
destination: 65.122.178.73, 63.228.223.104

traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets
1 er-rz-gig-3-3.stw-bonn.de (131.220.99.62) 1.792 ms 1.275 ms 1.125 ms
2 xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) 0.705 ms 2.132 ms 0.755 ms
3 xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) 1.477 ms 1.936 ms 1.051 ms
4 zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) 4.034 ms 3.734 ms 4.957 ms
5 64.213.78.237 (64.213.78.237) 3.866 ms 3.295 ms 26.854 ms
6 jfk-brdr-04.inet.qwest.net (63.146.26.225) 119.511 ms 92.735 ms 99.019 ms
7 * * *

or quote from DE-CIX tech-list:

[www.microsoft.com]
---
We also have some connectivity problems to ms, changing the bgp routing to
another tier 1 carrier don t resolve the problem
---



we shut down GBLX and routing now goes via Telia. Seems this helped. Looks
like there is an issue in the path GBLX - Qwest - ?

  Thomas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Valdis . Kletnieks]

On Thu, 07 Oct 2010 12:10:37 -, Sven Olaf Kamphuis said:
> If what you're asking under point c is "what happens if a system that 
> contains such a password for your email address gets compromised" the 
> answer is simple, you remove that specific password from your approved 
> passwords list

140 million or so compromised systems.  You may be spending a lot of time
removing compromised passwords from your list - and even more problematic,
notifying everybody of the *new* password(s) they should use to e-mail to you.
So far this month, I've seen 4,964 mails from 1,090 different From: lines
(mostly due to a subscription to the linux-kernel list, which is a true fire
hose), and some 250 different SMTP MAIL FROM: sources.

>  (note that on the receiver side, the password is not 
> linked 
> to the source email address, senders can use any source email address they 
> want, as long as one of the currently active/accepted passwords is in the 
> email)

We'll overlook the fact that if the password isn't linked to the source
address, then *any* sender can use any source they want, as long as as it's
known that *some* sender used '97%-chicken-teriyaki' as a password.  And with
140 million compromised boxes, there's a basically never-ending supply of
credentials to be stolen and used.

> remaining problems with this system are:
> by lack of a standard header for Password: which should be supported by 
> all clients, address books, online shops, mailinglists, we put the 
> password in the email, which means, that on Cc:'s and forwards etc
> the password got forwarded along with the email, potentially giving other 
> people the password too.

And you recognize that your scheme leaks said passwords, but that's not a fatal
problem.

> Now, this is -100%- spam stopping, smtp can be as open relay and you want, 
> the internet can be full of compromised windows boxes chunking out tons of 
> crap, but you won't get any spam, just mail from people YOU choose to deal 
> with, by actively -giving- them a password yourself, which you can also 
> -revoke-.

So explain to me in *detail* - you're in the To: line of this mail.  I don't
believe I've sent to you in the past.  I acquire a password valid to send you
this e-mail, how, exactly? After all, I can't e-mail you and ask for one...

After that, explain how a Hotmail user migrates to GMail (or vice versa) and
retains their ability to contact everybody they used to contact.

You might want to look at this:

http://www.rhyolite.com/anti-spam/you-might-be.html

and see how many of the entries in the list apply to your proposal. (Nothing
personal - I don't think *any* realistic anti-spam proposal can get much
traction unless they've at least *thought* about every single bullet point on
that list).

Further discussion is probably best on SPAM-L.



pgpSCDeDKmbOX.pgp
Description: PGP signature

Re: reachability problems Europe->US?

[Thomas Schmid]

Hi,

On 07.10.2010 14:35, Heath Jones wrote:

Seems to be only source-prefix-based, but several ISPs in europe are affected.

Can you post source and destination IP's ?


source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21,
destination: 65.122.178.73, 63.228.223.104

traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets
 1  er-rz-gig-3-3.stw-bonn.de (131.220.99.62)  1.792 ms  1.275 ms  1.125 ms
 2  xr-bon1-te2-3.x-win.dfn.de (188.1.233.193)  0.705 ms  2.132 ms  0.755 ms
 3  xr-bir1-te2-3.x-win.dfn.de (188.1.144.9)  1.477 ms  1.936 ms  1.051 ms
 4  zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46)  4.034 ms  3.734 ms  4.957 ms
 5  64.213.78.237 (64.213.78.237)  3.866 ms  3.295 ms  26.854 ms
 6  jfk-brdr-04.inet.qwest.net (63.146.26.225)  119.511 ms  92.735 ms  99.019 ms
 7  * * *

or quote from DE-CIX tech-list:

[www.microsoft.com]
---
We also have some connectivity problems to ms, changing the bgp routing to
another tier 1 carrier don t resolve the problem
---

Cheers,

 Thomas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: P2P link over STM-1

[Matthew Petach]

On Thu, Oct 7, 2010 at 1:24 AM, Peter Rudasingwa
 wrote:
> I have clients who want a P2P link over STM-1.
>
> How can I achieve this? What kind of equipment do I need.
>
> At the moment I have a cisco 6500 and 7200VXR
>
> Thanks,
>
> Peter R.


Aren't STM-1 links, by their very nature, point-to-point links?

I don't think it's very clear what it is you're trying to do that's
out of the ordinary here--can you clarify what it is you're
trying to achieve?

Thanks!

Matt

Re: reachability problems Europe->US?

[Heath Jones]

>Seems to be only source-prefix-based, but several ISPs in europe are affected.
Can you post source and destination IP's ?

reachability problems Europe->US?

[Thomas Schmid]

Hi,

any known problems with reachability from europe to US? We have
customer complaints that they can't reach US-based sites like microsoft and
others. Seems to be only source-prefix-based, but several ISPs in europe
are affected.

Or is the same problem visible in the states?

Regards,

  Thomas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: New hijacking - Done via via good old-fashioned Identity Theft

[Sven Olaf Kamphuis]

we have run a simular system for a while, the problem is still with 
mailinglists and online shops


(by lack of a standardised field the password was put anywhere in the 
email, all email not containing a password was rejected with a message to 
call sales)


a) you print unique passwords on each businesscard, and simply give them 
to your clients through other means (sales telephone number, etc)


b) there is no O(N^2) scaling. you currently have an email address, and 
maybe a name for everyone you want to email in your address book, or your 
database, all thats required is another field with the password they gave 
you.


c) totally fine, with us, it stopped 100% of all undesired email (normally 
1500 a day just for me alone ;)


If what you're asking under point c is "what happens if a system that 
contains such a password for your email address gets compromised" the 
answer is simple, you remove that specific password from your approved 
passwords list (note that on the receiver side, the password is not linked 
to the source email address, senders can use any source email address they 
want, as long as one of the currently active/accepted passwords is in the 
email)


remaining problems with this system are:
by lack of a standard header for Password: which should be supported by 
all clients, address books, online shops, mailinglists, we put the 
password in the email, which means, that on Cc:'s and forwards etc
the password got forwarded along with the email, potentially giving other 
people the password too.


Now, this is -100%- spam stopping, smtp can be as open relay and you want, 
the internet can be full of compromised windows boxes chunking out tons of 
crap, but you won't get any spam, just mail from people YOU choose to deal 
with, by actively -giving- them a password yourself, which you can also 
-revoke-.


(the initial contact, the equivalent of "accept contact" in skype simply 
needs to be done through other channels, but really, people that don't know

you have no business mailing you anyway ;)

We have been watching these so-called "spam fighters" for a while now, and 
all they managed to do over the past 20 years or so is completely fuck up 
the smtp protocol itself, first they fucked up the concept of open relays, 
then it was stupid and unnessesary delays (graylisting), then there were

all kinds of blacklists run by arrogant fools that gladly blacklisted all
of level 3 because of one spammer, etc, and you still got spammed, and 
still get spammed today.


If i have to wait for 20 minutes for an email, i've started skype 
already.. You know what, why don't we simply turn the smtp servers -off-

and use skype and msn for everything... saves electricity :P

It may be a bit too late to fix the protocol itself to be real-time and 
peer-to-peer again, but this time without spam ofcourse, as the market has 
been flooded with better protocols already anyway (the problem with these 
however is that they're propriatory and vendor dependant).


--
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=
Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
 D-13359   Registration:HRA 42834 B
 BERLINPhone:   +31/(0)87-8747479
 Germany   GSM: +49/(0)152-26410799
RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
=
 C3P0, der elektrische Westerwelle

=

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Wed, 6 Oct 2010, Rich Kulawiec wrote:


On Wed, Oct 06, 2010 at 10:14:27PM +, Sven Olaf Kamphuis wrote:

(keep in mind, each sender gets a unique password from the receiver,
this can be stored in the address book along with the email address
itself).


I'd like to see the I-D which explains how this is going to work,
with particular attention to (a) how the passwords will be exchanged
without using email (b) how it's going to handle the O(N^2) scaling and
(c) how it's going to work in an environment with at least a hundred
million compromised systems -- that is, systems that are now owned by
the enemy, who thus also owns the contents of all the address books
stored on them...including all the passwords.  I think once these
issues are addressed it will be only a small matter of implementation
to convince everyone to swiftly move to a different protocol for mail.

---rsk

DNS/Proxy based DDoS protection

[Drew Weaver]

Hi,

Over the last several years I've noticed there seems to be no limit to the 
number of proxy/DNS based DDoS protection services springing up all over the 
place so I am wondering if anyone has any insights on what sorts of tools, etc 
these companies use to provide this service (Open Source, Commercial?) and if 
anyone has any thoughts or experiences regarding the effectiveness of these 
types of services to protect HTTP services.

thanks,
-Drew

P2P link over STM-1

[Peter Rudasingwa]

I have clients who want a P2P link over STM-1.

How can I achieve this? What kind of equipment do I need.

At the moment I have a cisco 6500 and 7200VXR

Thanks,

Peter R.