32-bit AS numbers
Hi all, As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/ affiliation and whether I can quote you or not. Iljitsch
Re: Dutch ISPs to collaborate and take responsibility
On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: Additionally the problems of DDOS sourced from a collection of compromised hosts could be interfering with someone else's ability to make a successful VOIP call. Much more than that: they could be interfering with the underlying infrastructure, or they could be attacking the VOIP destination, or they could be making fake VOIP calls (see below), or they could be doing ANYTHING. A compromised system is enemy territory, which is why: This blocking should be as narrow as possible. Blocking should be total. A compromised system is as much enemy-controlled as if it were physically located at the RBN. Trying to figure out which of externally-visible behaviors A, B, C, etc. it exhibits might be malicious and which might not be is a loss, doubly so given that many of the attacks launched by such systems are of a distributed nature and thus are very difficult to infer solely by observation of one system. Moreover, there is no way to know, given a current observation of behavior A, whether or not behavior B will begin, when it will begin, or what it will be. For example, there's no way to know that a supposed VOIP call to 911 from that system is actually being made by a human being. It's certainly well within the capabilities of malware to place such a call -- and abuses of 911 in efforts to misdirect authorities are well-known. (See swatting. And note that nothing stops a botnet equipped with appropriate s/w from launching a number of such calls in sequence, with what I think are predictable consequences.) The bottom line is that once a system is compromised, all bets are off. Nothing it does can be trusted by anyone: not its *former* owners, not the network operator, not anyone in receipt of its traffic. So the only logical course of action is to cut it off completely, as quickly as possible, and keep it that way until it's properly fixed. (Which of course involves booting from known-clean media, restoring apps from known-clean sources, scanning all user data, etc. Booting from known-infected media is an obvious and immediate fail.) ---Rsk
109/8 - not a BOGON
Hi there, A customer of mine is reporting that there are a large number of addresses he can not reach with his addresses in the 109/8 range. This was declassified as a BOGON and assigned by IANA to RIPE in January 2009. If you have a manually updated BOGON list, can I please ask that you review it and update it as soon as possible please? His addresses in 89/8 and 83/8 work just fine, hence this presumption of BOGON filtering. Matthew Walster
Re: 109/8 - not a BOGON
Hi Matthew, I had the same problem with our new range assigned to us by APNIC, out of 110/8 You're in for a long, hard and frustrating road. If you manage to get in contact with anyone, or anyone responds to you, mind letting me know? I'd suspect they'd probably have us blocked still too, we've just not come across it yet. Regards, Shane Short On 09/10/2009, at 7:22 PM, Matthew Walster wrote: Hi there, A customer of mine is reporting that there are a large number of addresses he can not reach with his addresses in the 109/8 range. This was declassified as a BOGON and assigned by IANA to RIPE in January 2009. If you have a manually updated BOGON list, can I please ask that you review it and update it as soon as possible please? His addresses in 89/8 and 83/8 work just fine, hence this presumption of BOGON filtering. Matthew Walster
RE: 109/8 - not a BOGON
The 109/8 range was removed from our ISP Ingress Prefix Filters in version 22 (dated 6-Feb-2009): ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Template s/T-ip-prefix-filter-ingress-loose-check-v22.txt Thanks, John -Original Message- From: Matthew Walster [mailto:matt...@walster.org] Sent: Friday, October 09, 2009 7:22 AM To: nanog@nanog.org Subject: 109/8 - not a BOGON Hi there, A customer of mine is reporting that there are a large number of addresses he can not reach with his addresses in the 109/8 range. This was declassified as a BOGON and assigned by IANA to RIPE in January 2009. If you have a manually updated BOGON list, can I please ask that you review it and update it as soon as possible please? His addresses in 89/8 and 83/8 work just fine, hence this presumption of BOGON filtering. Matthew Walster
Re: 109/8 - not a BOGON
On 09/10/2009 4:22, Matthew Walster matt...@walster.org wrote: A customer of mine is reporting that there are a large number of addresses he can not reach with his addresses in the 109/8 range. This was declassified as a BOGON and assigned by IANA to RIPE in January 2009. If you have a manually updated BOGON list, can I please ask that you review it and update it as soon as possible please? His addresses in 89/8 and 83/8 work just fine, hence this presumption of BOGON filtering. This might be a good moment to list all the /8s allocated so far this year. 046/8RIPE NCC2009-09whois.ripe.net ALLOCATED 002/8RIPE NCC2009-09whois.ripe.net ALLOCATED 182/8APNIC 2009-08whois.apnic.netALLOCATED 175/8APNIC 2009-08whois.apnic.netALLOCATED 183/8APNIC 2009-04whois.apnic.netALLOCATED 180/8APNIC 2009-04whois.apnic.netALLOCATED 178/8RIPE NCC2009-01whois.ripe.net ALLOCATED 109/8RIPE NCC2009-01whois.ripe.net ALLOCATED Also, I'd like to mention that if you ever want to check your filters against the registry, we have made the columns sortable. It's now nice and easy to identify newly allocated /8s. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Regards, Leo Vegoda
Invalid prefix announcement from AS9035 for 129.77.0.0/16
About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16
Hi Matthew, You are not the only one having this issue. They are announcing some other prefixes as well! 2009/10/9 Matthew Huff mh...@ox.com About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -- Wouter Prins w...@null0.nl 0x301FA912
Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16
Agreed. Our prefixes at AS40060 were announced as well. I received a notification around 7:00am EDT that our prefixes were detected announced from AS9035 with the same upstream AS1267. On 10/9/09 8:34 AM, Wouter Prins w...@null0.nl wrote: Hi Matthew, You are not the only one having this issue. They are announcing some other prefixes as well! 2009/10/9 Matthew Huff mh...@ox.com About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761
RE: 32-bit AS numbers
Hi Iljitsch- This statement isnt entirely correct. Im not sure if this is just a word smithing error in your email or if the management of this issue in the ARIN region isnt well known. I can only address the ARIN region but in that region if there is a 16 bit ASN in the free pool it will be given out before a 32 bit one. They are going to manage the ASN free pool by lower bit number out first. Granted if zero 16 bit ASN's are in the pool then the only thing going out at the time would be a 32 bit ASN. However, I just wanted to clarify for the ARIN region that 16 bit ASN assignments will not be halted. If they exist in the free pool they will be used. Cheers! Marla Azinger Frontier Communications -Original Message- From: Iljitsch van Beijnum [mailto:iljit...@muada.com] Sent: Friday, October 09, 2009 1:32 AM To: NANOG list Subject: 32-bit AS numbers Hi all, As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/ affiliation and whether I can quote you or not. Iljitsch
RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16
We also received a notification that our IP block 67.135.55.0/24 (AS19629) is being annouced by AS9035. Hopefully someone is receiving my emails. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.eb...@crlmed.com www.consultingradiologists.com -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Friday, October 09, 2009 7:28 AM To: nanog@nanog.org Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16
Lots of people were affected, but none significantly. They originated 86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't think anyone outside Telecom Italia's customer cone even saw them. So the impact was really, really limited. The correct origins were being reasserted even before the last of the announcements came over the wire. It always irks me when I see routing alerts that arrive hours after the event is over, without any of the context that would allow you to know whether it had any real impact. Your instinct to check looking glasses is the right one, but you have to move quickly and know where to look. Of course, I'm biased.--jim On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy akenn...@cyberlinktech.comwrote: Agreed. Our prefixes at AS40060 were announced as well. I received a notification around 7:00am EDT that our prefixes were detected announced from AS9035 with the same upstream AS1267. On 10/9/09 8:34 AM, Wouter Prins w...@null0.nl wrote: Hi Matthew, You are not the only one having this issue. They are announcing some other prefixes as well! 2009/10/9 Matthew Huff mh...@ox.com About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761
Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16
We are seeing the same ting with 66.146.192.0/19 66.251.224.0/19. According to cyclopes this is still continuing. . . Dylan Ebner wrote: We also received a notification that our IP block 67.135.55.0/24 (AS19629) is being annouced by AS9035. Hopefully someone is receiving my emails. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.eb...@crlmed.com www.consultingradiologists.com -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Friday, October 09, 2009 7:28 AM To: nanog@nanog.org Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16
Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner -Original Message- From: Jim Cowie [mailto:co...@renesys.com] Sent: Friday, October 09, 2009 9:11 AM To: Adam Kennedy Cc: NANOG Subject: Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Lots of people were affected, but none significantly. They originated 86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't think anyone outside Telecom Italia's customer cone even saw them. So the impact was really, really limited. The correct origins were being reasserted even before the last of the announcements came over the wire. It always irks me when I see routing alerts that arrive hours after the event is over, without any of the context that would allow you to know whether it had any real impact. Your instinct to check looking glasses is the right one, but you have to move quickly and know where to look. Of course, I'm biased.--jim On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy akenn...@cyberlinktech.comwrote: Agreed. Our prefixes at AS40060 were announced as well. I received a notification around 7:00am EDT that our prefixes were detected announced from AS9035 with the same upstream AS1267. On 10/9/09 8:34 AM, Wouter Prins w...@null0.nl wrote: Hi Matthew, You are not the only one having this issue. They are announcing some other prefixes as well! 2009/10/9 Matthew Huff mh...@ox.com About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761
RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16
I just received confirmation from AS9035 that they are not annoucing my IP block. Dylan Ebner, Network Engineer -Original Message- From: sjk [mailto:s...@sleepycatz.com] Sent: Friday, October 09, 2009 9:20 AM Cc: nanog@nanog.org Subject: Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16 We are seeing the same ting with 66.146.192.0/19 66.251.224.0/19. According to cyclopes this is still continuing. . . Dylan Ebner wrote: We also received a notification that our IP block 67.135.55.0/24 (AS19629) is being annouced by AS9035. Hopefully someone is receiving my emails. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.eb...@crlmed.com www.consultingradiologists.com -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Friday, October 09, 2009 7:28 AM To: nanog@nanog.org Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16
Usually I get alerts from BGPMon within about 20 minutes of an event being detected. Not so much with the event this morning. I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... -Original Message- From: Dylan Ebner [mailto:dylan.eb...@crlmed.com] Sent: Friday, October 09, 2009 10:23 AM To: Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner
Time Warner/Road Runner issues in the Mid West
Is anyone else seeing connectivity issues to the internet using Time Warner/Road Runner in the Mid West? Kansas City and Wisconsin seem to be unable to access sites on the west coast...
RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16
I thought that may be the case as well. Do people know of other services like BGPMon that may be able to keep up with the load better? Does anyone know how cyclops faired this morning with the additional load? Dylan Ebner -Original Message- From: Andrew Nusbaum [mailto:andrew.nusb...@mindspark.com] Sent: Friday, October 09, 2009 9:27 AM To: Dylan Ebner; Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Usually I get alerts from BGPMon within about 20 minutes of an event being detected. Not so much with the event this morning. I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... -Original Message- From: Dylan Ebner [mailto:dylan.eb...@crlmed.com] Sent: Friday, October 09, 2009 10:23 AM To: Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner
Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16
there are multiple systems available, sign up for a few i've noticed cyclops alerts are sent faster than bgpon PHAS was fast, but the project is over and something new is going to be released there is ripe MyASN there is watchmynet and IAR On Fri, Oct 9, 2009 at 7:23 AM, Dylan Ebner dylan.eb...@crlmed.com wrote: Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner -Original Message- From: Jim Cowie [mailto:co...@renesys.com] Sent: Friday, October 09, 2009 9:11 AM To: Adam Kennedy Cc: NANOG Subject: Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Lots of people were affected, but none significantly. They originated 86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't think anyone outside Telecom Italia's customer cone even saw them. So the impact was really, really limited. The correct origins were being reasserted even before the last of the announcements came over the wire. It always irks me when I see routing alerts that arrive hours after the event is over, without any of the context that would allow you to know whether it had any real impact. Your instinct to check looking glasses is the right one, but you have to move quickly and know where to look. Of course, I'm biased. --jim On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy akenn...@cyberlinktech.comwrote: Agreed. Our prefixes at AS40060 were announced as well. I received a notification around 7:00am EDT that our prefixes were detected announced from AS9035 with the same upstream AS1267. On 10/9/09 8:34 AM, Wouter Prins w...@null0.nl wrote: Hi Matthew, You are not the only one having this issue. They are announcing some other prefixes as well! 2009/10/9 Matthew Huff mh...@ox.com About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761
RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16
I actually got origin change alerts from Cyclops about 2 minutes after the announcements started. -Andy -Original Message- From: Dylan Ebner [mailto:dylan.eb...@crlmed.com] Sent: Friday, October 09, 2009 10:31 AM To: Andrew Nusbaum; Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 I thought that may be the case as well. Do people know of other services like BGPMon that may be able to keep up with the load better? Does anyone know how cyclops faired this morning with the additional load? Dylan Ebner -Original Message- From: Andrew Nusbaum [mailto:andrew.nusb...@mindspark.com] Sent: Friday, October 09, 2009 9:27 AM To: Dylan Ebner; Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Usually I get alerts from BGPMon within about 20 minutes of an event being detected. Not so much with the event this morning. I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... -Original Message- From: Dylan Ebner [mailto:dylan.eb...@crlmed.com] Sent: Friday, October 09, 2009 10:23 AM To: Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner
Re: 32-bit AS numbers
On Fri, Oct 09, 2009 at 10:31:52AM +0200, Iljitsch van Beijnum wrote: As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/affiliation and whether I can quote you or not. Chris Malayter and I gave a presentation at NANOG45 earlier this year that touches on some of the operational issues. http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf We also started a Wiki with content based on the presentation that has more updated information, including a current list of vendor support. If you see a vendor missing, let us know and we can update the list. Or better yet, create an account and add some content yourself :-). http://as4.cluepon.net/index.php/Main_Page Greg -- Greg Hankins ghank...@mindspring.com
Re: Time Warner/Road Runner issues in the Mid West
On Fri, Oct 09, 2009 at 07:30:19AM -0700, Mike Maberry wrote: Is anyone else seeing connectivity issues to the internet using Time Warner/Road Runner in the Mid West? Kansas City and Wisconsin seem to be unable to access sites on the west coast... Mike, There is an ongoing issue that our ops folks are currently troubleshooting. I don't have any details at this time, but if you've got a traceroute or other details on the specific issue that you're seeing, feel free to forward to me directly and I'll make sure it gets to the right parties here. Thanks, --Jeff
Re: 32-bit AS numbers
Greg Hankins wrote: We also started a Wiki with content based on the presentation that has more updated information, including a current list of vendor support. If you see a vendor missing, let us know and we can update the list. Or better yet, create an account and add some content yourself :-). http://as4.cluepon.net/index.php/Main_Page While it's good to see support _finally_ in 2.2SX, I still don't see it in 12.2SR (for rsp720). It's almost like Cisco has no idea how many of these things are actually used on the Internet. - Kevin
Re: 32-bit AS numbers
On Oct 9, 2009, at 12:05 PM, Kevin Loch wrote: Greg Hankins wrote: We also started a Wiki with content based on the presentation that has more updated information, including a current list of vendor support. If you see a vendor missing, let us know and we can update the list. Or better yet, create an account and add some content yourself :-). http://as4.cluepon.net/index.php/Main_Page While it's good to see support _finally_ in 2.2SX, I still don't see it in 12.2SR (for rsp720). It's almost like Cisco has no idea how many of these things are actually used on the Internet. One can use the 23456 method in the interim, but I'd rather see everyone deploy 4-byte code. There have already been cases already of people putting 23456 in an as4_path inappropriately. - Jared
RE: 32-bit AS numbers
While it's good to see support _finally_ in 2.2SX, I still don't see it in 12.2SR (for rsp720). It's almost like Cisco has no idea how many of these things are actually used on the Internet. This is actually our issue as well. Our backbone runs primarily RSP720's (with some Sup720's for good measure). Support in 12.2SRx would be much appreciated if anyone from Cisco product is listening. Regards, Randy
RE: 32-bit AS numbers
We are running into the same issues regarding 12.0 train for 12008 GSR w/PRP-2's. Even though there are IOS's that have a fixed 4 Byte ASN code...it has other bugs in NSF-SSO that we use here extensively. So hence the reason we are waiting to upgrade. Larry May Network Services n|Frame 888-223-8633 -Original Message- From: Randy Epstein [mailto:repst...@chello.at] Sent: Friday, October 09, 2009 12:17 PM To: 'Kevin Loch'; nanog@nanog.org Subject: RE: 32-bit AS numbers While it's good to see support _finally_ in 2.2SX, I still don't see it in 12.2SR (for rsp720). It's almost like Cisco has no idea how many of these things are actually used on the Internet. This is actually our issue as well. Our backbone runs primarily RSP720's (with some Sup720's for good measure). Support in 12.2SRx would be much appreciated if anyone from Cisco product is listening. Regards, Randy
Re: Time Warner/Road Runner issues in the Mid West
Mike Maberry wrote: Is anyone else seeing connectivity issues to the internet using Time Warner/Road Runner in the Mid West? Kansas City and Wisconsin seem to be unable to access sites on the west coast... Still ongoing in los angeles,
wanted: facebook technical contact
howdy, I'm chasing a technical contact at Facebook. There's some broken HTTP being served which is confusing Squid in a way that isn't easily, cleanly worked around. Please feel free to contact me off-list. Thanks, Adrian
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 10 Oct, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 299909 Prefixes after maximum aggregation: 140664 Deaggregation factor: 2.13 Unique aggregates announced to Internet: 148721 Total ASes present in the Internet Routing Table: 32379 Prefixes per ASN: 9.26 Origin-only ASes present in the Internet Routing Table: 28138 Origin ASes announcing only one prefix: 13738 Transit ASes present in the Internet Routing Table:4241 Transit-only ASes present in the Internet Routing Table:102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 560 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs:292 Prefixes from 32-bit ASNs in the Routing Table: 213 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:190 Number of addresses announced to Internet: 2112370016 Equivalent to 125 /8s, 232 /16s and 53 /24s Percentage of available address space announced: 57.0 Percentage of allocated address space announced: 64.6 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.3 Total number of prefixes smaller than registry allocations: 144194 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:71884 Total APNIC prefixes after maximum aggregation: 25318 APNIC Deaggregation factor:2.84 Prefixes being announced from the APNIC address blocks: 68393 Unique aggregates announced from the APNIC address blocks:30300 APNIC Region origin ASes present in the Internet Routing Table:3816 APNIC Prefixes per ASN: 17.92 APNIC Region origin ASes announcing only one prefix: 1047 APNIC Region transit ASes present in the Internet Routing Table:587 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 461684000 Equivalent to 27 /8s, 132 /16s and 189 /24s Percentage of available APNIC address space announced: 78.6 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks43/8, 58/8, 59/8, 60/8, 61/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, 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, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:126884 Total ARIN prefixes after maximum aggregation:66823 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 101398 Unique aggregates announced from the ARIN address blocks: 38471 ARIN Region origin ASes present in the Internet Routing Table:13278 ARIN Prefixes per ASN: 7.64 ARIN Region origin ASes announcing only one prefix:5135 ARIN Region transit ASes present in the Internet Routing Table:1301 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 706797568 Equivalent to 42 /8s, 32 /16s and 224 /24s Percentage of available ARIN address space announced: 62.0 ARIN
Re: wanted: facebook technical contact
A few people have asked what the specific problem is. http://www.squid-cache.org/mail-archive/squid-dev/200910/0089.html Adrian On Sat, Oct 10, 2009, Adrian Chadd wrote: howdy, I'm chasing a technical contact at Facebook. There's some broken HTTP being served which is confusing Squid in a way that isn't easily, cleanly worked around. Please feel free to contact me off-list.
Re: wanted: facebook technical contact
It is a HTTP/1.0 vs HTTP/1.1 thing (Chunked encoding for HTTP/1.1 doesn't require you to calculate and send a Content-Length.) Adrian On Fri, Oct 09, 2009, Jared Mauch wrote: I've been having the same issue when going through my Linux+Squid+WCCP setup, but if the browser is configured to go direct to the proxy it does not seem to have the same issue. (At least so far). - Jared On Oct 9, 2009, at 2:48 PM, Adrian Chadd wrote: A few people have asked what the specific problem is. http://www.squid-cache.org/mail-archive/squid-dev/200910/0089.html Adrian On Sat, Oct 10, 2009, Adrian Chadd wrote: howdy, I'm chasing a technical contact at Facebook. There's some broken HTTP being served which is confusing Squid in a way that isn't easily, cleanly worked around. Please feel free to contact me off-list. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: ISP customer assignments
How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere. Separate these technical issues from IPv6 allocation plans. If you intend to continue running an ISP in two years from now, either make a simple plan and allocate a /48 to every customer site, whether or not they are currently taking an IPv6 service from you. Or, take the slightly more complex plan and allocate a /56 per site where it is known for sure, 100% that the site is a private residence. If it is not, or there is doubt, then allocate a /48. I expect we won't invest any more into dial-up equipment, and when a dial-up customer happens to ask about IPv6 (if ever), we'll strongly encourage them to move to broadband, and as a last resort manually configure a /64 tunnel to them. You might use up a /64 for the two tunnel endpoints, but be sure to allocate the customer at least a /56. What are other providers doing, or considering doing? In general, big providers are not going to attempt to cope with any older equipment that does not fully support IPv6. But small providers will be rather innovative and try things like your tunnel suggestion. After all, if Hurricane Electric can run an IPv6 tunnel broker, why can't you? --Michael Dillon
BGP Update Report
BGP Update Report Interval: 01-Oct-09 -to- 08-Oct-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS919849597 4.6% 163.7 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS953128365 2.6%5673.0 -- GEDU-AS-KR Kwangju City Office Of Education 3 - AS165926099 2.4% 293.2 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 4 - AS845214240 1.3% 21.0 -- TEDATA TEDATA 5 - AS35805 11085 1.0% 25.0 -- UTG-AS United Telecom AS 6 - AS982910937 1.0% 25.0 -- BSNL-NIB National Internet Backbone 7 - AS4249 8936 0.8% 51.4 -- LILLY-AS - Eli Lilly and Company 8 - AS8866 7227 0.7% 20.2 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - AS7011 6663 0.6% 6.6 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 10 - AS5050 6127 0.6% 875.3 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - AS2697 5910 0.6% 107.5 -- ERX-ERNET-AS Education and Research Network 12 - AS141175909 0.6% 16.6 -- Telefonica del Sur S.A. 13 - AS176585787 0.5% 826.7 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 14 - AS4809 5767 0.5% 186.0 -- CHINATELECOM-CORE-WAN-CN2 China Telecom Next Generation Carrier Network 15 - AS5800 5732 0.5% 38.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 16 - AS335885713 0.5% 15.2 -- BRESNAN-AS - Bresnan Communications, LLC. 17 - AS309694927 0.5% 307.9 -- TAN-NET TransAfrica Networks 18 - AS7315 4861 0.5% 72.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 19 - AS179744801 0.5% 10.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS255244608 0.4% 18.0 -- OTON-AS SC Oton SRL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS953128365 2.6%5673.0 -- GEDU-AS-KR Kwangju City Office Of Education 2 - AS438803006 0.3%3006.0 -- LITECH-AS Laboratory of Information Technologies LLC 3 - AS5691 2797 0.3%2797.0 -- MITRE-AS-5 - The MITRE Corporation 4 - AS410601458 0.1%1458.0 -- PRIMBANK-AS Joint-Stock Commercial Bank Primorye 5 - AS362391277 0.1%1277.0 -- EXIGEN-CANADA - Exigen Canada 6 - AS43864 988 0.1% 988.0 -- INTEGRA-MEDIA-AS Integra-Media Ltd 7 - AS5050 6127 0.6% 875.3 -- PSC-EXT - Pittsburgh Supercomputing Center 8 - AS176585787 0.5% 826.7 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 9 - AS4628 1373 0.1% 686.5 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd 10 - AS238711358 0.1% 679.0 -- AINS-AS-AP Australia Internet Solutions 11 - AS249941136 0.1% 568.0 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes 12 - AS48728 460 0.0% 460.0 -- VODAFONEQATAR Vodafone Qatar Q.S.C. 13 - AS43008 446 0.0% 446.0 -- TREND-AS TREND IMPORT-EXPORT SRL 14 - AS5814 400 0.0% 400.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS39803 749 0.1% 374.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 16 - AS35301 747 0.1% 373.5 -- CCCMOS-AS CCCMOS GROUP AS Numbers 17 - AS6036 3801 0.3% 345.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS2642 1710 0.2% 342.0 -- LEG-CA-GOV - State of California 19 - AS309694927 0.5% 307.9 -- TAN-NET TransAfrica Networks 20 - AS179642436 0.2% 304.5 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 6106 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 113.11.156.0/245751 0.5% AS17658 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 3 - 211.253.68.0/225673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 4 - 211.253.72.0/215673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 5 - 210.218.64.0/195673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 6 - 210.217.224.0/19 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 7 - 210.218.0.0/18 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 8 - 88.204.221.0/245334 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 89.218.218.0/235325 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 89.218.220.0/235322 0.5% AS9198 -- KAZTELECOM-AS
The Cidr Report
This report has been generated at Fri Oct 9 21:11:14 2009 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
02-10-09304773 185941
03-10-09304871 185817
04-10-09304733 186089
05-10-09304982 186215
06-10-09304949 186567
07-10-09305120 186994
08-10-09305290 187266
09-10-09305384 187248
AS Summary
32540 Number of ASes in routing system
13844 Number of ASes announcing only one prefix
4311 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
89611776 Largest address span announced by an AS (/32s)
AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center
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').
--- 09Oct09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 305474 187286 11818838.7% All ASes
AS6389 4163 325 383892.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4311 1787 252458.5% TWTC - tw telecom holdings,
inc.
AS4766 1881 582 129969.1% KIXS-AS-KR Korea Telecom
AS17488 1460 288 117280.3% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS18566 1062 10 105299.1% COVAD - Covad Communications
Co.
AS22773 73 103893.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS1785 1762 841 92152.3% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS8151 1483 577 90661.1% Uninet S.A. de C.V.
AS4755 1261 397 86468.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS18101 979 183 79681.3% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS19262 1020 231 78977.4% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1405 631 77455.1% ATT-INTERNET3 - ATT WorldNet
Services
AS10620 1020 250 77075.5% TV Cable S.A.
AS8452 984 263 72173.3% TEDATA TEDATA
AS3356 1222 537 68556.1% LEVEL3 Level 3 Communications
AS4804 680 90 59086.8% MPX-AS Microplex PTY LTD
AS17908 638 59 57990.8% TCISL Tata Communications
AS4808 762 188 57475.3% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS24560 774 207 56773.3% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS7303 655 100 55584.7% Telecom Argentina S.A.
AS9498 650 112 53882.8% BBIL-AP BHARTI Airtel Ltd.
AS11492 1133 605 52846.6% CABLEONE - CABLE ONE, INC.
AS22047 545 18 52796.7% VTR BANDA ANCHA S.A.
AS7018 1543 1056 48731.6% ATT-INTERNET4 - ATT WorldNet
Services
AS17676 562 125 43777.8% GIGAINFRA Softbank BB Corp.
AS5668 801 365 43654.4% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS4780 564 143 42174.6% SEEDNET Digital United Inc.
AS7011 1023 616 40739.8% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS855625 222 40364.5% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS28573 763 362 40152.6% NET Servicos de Comunicao S.A.
Total 36842112432559969.5% Top 30 total
Possible Bogus Routes
24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC.
Re: Does Internet Speed Vary by Season?
On 7-Oct-09, at 11:22 AM, Scott Morris wrote: I may be having my wires a little crossed (I'm not an electrical engineer) but I was always under the impression that manipulation of the physical characteristics like that from heat/dampness didn't reduce the speed but the quality (like line noise/errors/etc) of the line. Well, since it's been documented that internet speed / usage varies with the weather (it gets faster when it's sunny, slower when it rains) I'm sure some seasonal correlation could be found. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June 16/17 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp
RE: Does Internet Speed Vary by Season?
I may be missing a little bit here by jumping a bit in the thread so sorry. What is the difference between weather and seasonal? I define weather like, well its cloudy and raining here and get in the car and drive 20 minutes and it is clear and sunny. I would call this mostly localized, like ground zero. Nice here bad 15 miles/minutes away. Seasonal, well I think of Seattle, almost always rain/clouds..., more than a 15 minute/mile radius. Seasonal reminds me more of say, for months straight the ground/air is well, frozen. Like the northeast, where I used to live and will never go back. Just my .02, I'll shut up now. -Original Message- From: Dragos Ruiu [mailto:d...@kyx.net] Sent: Friday, October 09, 2009 8:38 PM To: s...@emanon.com Cc: nanog@nanog.org; Joe Greco Subject: Re: Does Internet Speed Vary by Season? On 7-Oct-09, at 11:22 AM, Scott Morris wrote: I may be having my wires a little crossed (I'm not an electrical engineer) but I was always under the impression that manipulation of the physical characteristics like that from heat/dampness didn't reduce the speed but the quality (like line noise/errors/etc) of the line. Well, since it's been documented that internet speed / usage varies with the weather (it gets faster when it's sunny, slower when it rains) I'm sure some seasonal correlation could be found. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June 16/17 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp
Re: Dutch ISPs to collaborate and take responsibility
On 10/9/09, Rich Kulawiec r...@gsp.org wrote: On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: Additionally the problems of DDOS sourced from a collection of compromised hosts could be interfering with someone else's ability to make a successful VOIP call. Much more than that: they could be interfering with the underlying infrastructure, or they could be attacking the VOIP destination, or they could be making fake VOIP calls (see below), or they could be doing ANYTHING. A compromised system is enemy territory, which is why: This blocking should be as narrow as possible. Blocking should be total. A compromised system is as much enemy-controlled as if it were physically located at the RBN. Trying to figure out which of externally-visible behaviors A, B, C, etc. it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised should be blocked. Lee
RE: Dutch ISPs to collaborate and take responsibility
or when I initiate offsite backups. I've seen ISPs that react to just traffic bursts. It's not the way to go without more intelligent decision making on the content (i.e. SMTP, all SYNs, etc). Of course, content inspection is a whole 'nother hornet's nest :) - S -Original Message- From: Lee ler...@gmail.com Sent: Friday, October 09, 2009 19:41 To: nanog@nanog.org nanog@nanog.org Subject: Re: Dutch ISPs to collaborate and take responsibility On 10/9/09, Rich Kulawiec r...@gsp.org wrote: On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: Additionally the problems of DDOS sourced from a collection of compromised hosts could be interfering with someone else's ability to make a successful VOIP call. Much more than that: they could be interfering with the underlying infrastructure, or they could be attacking the VOIP destination, or they could be making fake VOIP calls (see below), or they could be doing ANYTHING. A compromised system is enemy territory, which is why: This blocking should be as narrow as possible. Blocking should be total. A compromised system is as much enemy-controlled as if it were physically located at the RBN. Trying to figure out which of externally-visible behaviors A, B, C, etc. it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised should be blocked. Lee
Re: Dutch ISPs to collaborate and take responsibility
Lee wrote: If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised should be blocked. Lee Some info. here (from http://networkmanagement.comcast.net/ ): 5. Detection of Bots http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03 http://tools.ietf.org/html/draft-livingood-web-notification-00
