Re: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts
On Wed, Aug 7, 2013 at 2:31 PM, Phil Fagan philfa...@gmail.com wrote: BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it wasn't reachable? Is this an artifact? In a perfect world, people wouldn't advertise prefixes unless they knew they had reachability for those prefixes. Unfortunately, this a far, far from perfect world. Matt On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid chad.r...@apollogrp.edu wrote: Thanks for the assistance everyone. This issue was resolved by shutting down a BGP peering session between Time Warner and Comcast. --Chad Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services │ IT Operations Center (ITOC) 4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040 phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu -Original Message- From: Chad Reid Sent: Sunday, August 04, 2013 7:41 AM To: 'nanog@nanog.org' Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts Hello NANOG, A few hundred of our users that use Comcast in the South East United States (other regions aren't affected) are unable to access our websites in the IP block 204.17.16.0/20. Based upon testing with the users, they're getting a destination unreachable from a Comcast backbone router in ASN 7922: be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: Destination net unreachable. We're not a customer of Comcast, nor are any of our ISPs. Because of this, we can't find anyone at Comcast to look at this issue nor do we have good contact info to even reach someone. Our users in the South East can open tickets with Comcast technical support, but you can imagine how successful they are trying to explain this to frontline support and getting frontline support to understand. Is anyone from Comcast on the list that can assist or know of a contact? Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services │ IT Operations Center (ITOC) 4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040 phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. -- Phil Fagan Denver, CO 970-480-7618
Re: Strange entries from AS1 in global table
Looking at our routers I can see this: 3549 3356 26114 1 i 12956 1239 23520 23383 1 ? but neither 26114 or 23383 are Brazilian ISP´s. Anyway, I guess it´s probably leaked routes or even use of AS 1 as private one (I don´t think level3 guys are using this AS anymore...). Cheers, Humberto Galiza 2013/8/4 Anurag Bhatia m...@anuragbhatia.com: Hello everyone I was looking at global IPv4 table and saw some strange entries from AS1. As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of Brazil based ISP - Netvip http://bgp.he.net/AS1#_prefixes Looking at any prefix in detail, it seems like there are multiple ASNs announcing same prefix. E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 (Netvip's allocated ASN). Same is true with 177.185.98.0/24, 177.185.98.0/24and so on. http://bgp.he.net/net/177.185.96.0/24 So seems like AS1 acting like a mirror for all announcements of AS52931. To see who exactly gave transit to AS1 by Netvip in Brazil, I checked Oregon and noticed these routes: 3356 3549 16735 52931 1 i Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which seems like a backbone ISP in Brazil) is not filtering these routes further passing to Level3 (AS3549+AS3356). I am curious to know what could be possible reason for an ASN like AS1 acting in exact mirror of AS52931? Could it be a case of internal use of AS1 (assuming it to be private ASN)? May be it's a case of leaked internal routes? Appreciate your time answer. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: questions regarding prefix hijacking
They do happen, but they get little publicity. People that I've talked to about this say, for reasons mostly unspecified, they'd rather not talk about it. On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow morrowc.li...@gmail.comwrote: On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. do we really need that? they seem to occur often enough that that isn't really required :( -- -- = Carlos M. Martinez-Cagnazzo h http://cagnazzo.namettp://cagnazzo.me =
RE: Strange entries from AS1 in global table
Level 3 currently uses AS 1 in their MPLS network. I'm unsure if it's used elsewhere, but AS 1 could get into the AS paths of prefixes in the global routing table this way. I wouldn't expect to see it originating routes outside of the WAN interface for customers though and those are typically way too small to make it into the global routing table. -Vinny -Original Message- From: Humberto Galiza [mailto:humbertogal...@gmail.com] Sent: Thursday, August 08, 2013 6:25 AM To: Anurag Bhatia Cc: NANOG Mailing List Subject: Re: Strange entries from AS1 in global table Looking at our routers I can see this: 3549 3356 26114 1 i 12956 1239 23520 23383 1 ? but neither 26114 or 23383 are Brazilian ISP´s. Anyway, I guess it´s probably leaked routes or even use of AS 1 as private one (I don´t think level3 guys are using this AS anymore...). Cheers, Humberto Galiza 2013/8/4 Anurag Bhatia m...@anuragbhatia.com: Hello everyone I was looking at global IPv4 table and saw some strange entries from AS1. As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of Brazil based ISP - Netvip http://bgp.he.net/AS1#_prefixes Looking at any prefix in detail, it seems like there are multiple ASNs announcing same prefix. E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 (Netvip's allocated ASN). Same is true with 177.185.98.0/24, 177.185.98.0/24and so on. http://bgp.he.net/net/177.185.96.0/24 So seems like AS1 acting like a mirror for all announcements of AS52931. To see who exactly gave transit to AS1 by Netvip in Brazil, I checked Oregon and noticed these routes: 3356 3549 16735 52931 1 i Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which seems like a backbone ISP in Brazil) is not filtering these routes further passing to Level3 (AS3549+AS3356). I am curious to know what could be possible reason for an ASN like AS1 acting in exact mirror of AS52931? Could it be a case of internal use of AS1 (assuming it to be private ASN)? May be it's a case of leaked internal routes? Appreciate your time answer. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: questions regarding prefix hijacking
Saku, In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. What do you mean? In most cases upstreams do not filter prefixes at all? There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. Thanks for mentioning this! Very interesting effort. I validated some routes in LIR portal, verified that those are validated using RIPE rpki-validator tool and a Juniper router connected to validator: r...@lr1.ham1.de show validation session detail Session 195.13.63.18, State: up, Session index: 2 Group: eurotransit-testbed, Preference: 100 Local IPv4 address: 193.34.50.25, Port: 8282 Refresh time: 120s Hold time: 180s Record Life time: 3600s Serial (Full Update): 559 Serial (Incremental Update): 559 Session flaps: 0 Session uptime: 00:11:35 Last PDU received: 00:00:27 IPv4 prefix count: 4921 IPv6 prefix count: 833 r...@lr1.ham1.de show route protocol bgp 5.11.81.0 inet.0: 456407 destinations, 456408 routes (456407 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.11.81.0/24 *[BGP/170] 00:11:59, localpref 110, from 79.141.168.1 AS path: 33926 25577 43532 I, validation-state: valid to 193.34.50.1 via em0.0 RPKI-valid.inet.0: 11440 destinations, 11440 routes (11440 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.11.81.0/24 *[BGP/170] 00:11:11, localpref 110, from 79.141.168.1 AS path: 33926 25577 43532 I, validation-state: valid to 193.34.50.1 via em0.0 r...@lr1.ham1.de Massimiliano, Paul, Indra: thanks for pointing out those interesting cases! regards, Martin 2013/8/8, Carlos Martinez-Cagnazzo carlosm3...@gmail.com: They do happen, but they get little publicity. People that I've talked to about this say, for reasons mostly unspecified, they'd rather not talk about it. On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow morrowc.li...@gmail.comwrote: On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. do we really need that? they seem to occur often enough that that isn't really required :( -- -- = Carlos M. Martinez-Cagnazzo h http://cagnazzo.namettp://cagnazzo.me =
Re: Strange entries from AS1 in global table
I think Level(3) uses it for at least some L3 MPLS VPN stuff. We peer with that AS for dedicated SIP service transport for example. On Aug 8, 2013, at 5:25 AM, Humberto Galiza humbertogal...@gmail.com wrote: Looking at our routers I can see this: 3549 3356 26114 1 i 12956 1239 23520 23383 1 ? but neither 26114 or 23383 are Brazilian ISP´s. Anyway, I guess it´s probably leaked routes or even use of AS 1 as private one (I don´t think level3 guys are using this AS anymore...). Cheers, Humberto Galiza 2013/8/4 Anurag Bhatia m...@anuragbhatia.com: Hello everyone I was looking at global IPv4 table and saw some strange entries from AS1. As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of Brazil based ISP - Netvip http://bgp.he.net/AS1#_prefixes Looking at any prefix in detail, it seems like there are multiple ASNs announcing same prefix. E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 (Netvip's allocated ASN). Same is true with 177.185.98.0/24, 177.185.98.0/24and so on. http://bgp.he.net/net/177.185.96.0/24 So seems like AS1 acting like a mirror for all announcements of AS52931. To see who exactly gave transit to AS1 by Netvip in Brazil, I checked Oregon and noticed these routes: 3356 3549 16735 52931 1 i Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which seems like a backbone ISP in Brazil) is not filtering these routes further passing to Level3 (AS3549+AS3356). I am curious to know what could be possible reason for an ASN like AS1 acting in exact mirror of AS52931? Could it be a case of internal use of AS1 (assuming it to be private ASN)? May be it's a case of leaked internal routes? Appreciate your time answer. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: questions regarding prefix hijacking
On (2013-08-08 17:48 +0300), Martin T wrote: In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. What do you mean? In most cases upstreams do not filter prefixes at all? Exactly. Source data has usually low quality and even even data is high quality for many organization it's very complex task. Internet does not have very good MTBF what we are pretty good at is MTTR. -- ++ytti
Re: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts
It's a fair question and had nothing to do with the other network (TW Telecom, in this case, not TIme Warner Cable). Sorry for not filling in details sooner. We recently needed to adjust the scale profile on some of our Cisco ASR9k trident chip (80gig) Line Cards as we reached . The default profile only supports up to 512k routes and will notify that CEF has run out of DATA_TYPE_TABLE_SET space as a result. The profile change required (profile 13) requires a reload of the chassis. please be advised. You might want to review with your local support team. The symptom involved BGP neighbor instability and unreachability of some destinations. Shutting down that particular BGP session was a temporary work-around until the adjustment could be made during a demand maintenance window to minimize disruption. Thanks, Tony On Wed, Aug 7, 2013 at 5:31 PM, Phil Fagan philfa...@gmail.com wrote: BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it wasn't reachable? Is this an artifact? On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid chad.r...@apollogrp.edu wrote: Thanks for the assistance everyone. This issue was resolved by shutting down a BGP peering session between Time Warner and Comcast. --Chad Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services │ IT Operations Center (ITOC) 4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040 phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu -Original Message- From: Chad Reid Sent: Sunday, August 04, 2013 7:41 AM To: 'nanog@nanog.org' Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts Hello NANOG, A few hundred of our users that use Comcast in the South East United States (other regions aren't affected) are unable to access our websites in the IP block 204.17.16.0/20. Based upon testing with the users, they're getting a destination unreachable from a Comcast backbone router in ASN 7922: be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: Destination net unreachable. We're not a customer of Comcast, nor are any of our ISPs. Because of this, we can't find anyone at Comcast to look at this issue nor do we have good contact info to even reach someone. Our users in the South East can open tickets with Comcast technical support, but you can imagine how successful they are trying to explain this to frontline support and getting frontline support to understand. Is anyone from Comcast on the list that can assist or know of a contact? Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services │ IT Operations Center (ITOC) 4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040 phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. -- Phil Fagan Denver, CO 970-480-7618
Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On Aug 1, 2013, at 2:31 AM, Saku Ytti s...@ytti.fi wrote: On (2013-07-31 17:07 -0700), bottiger wrote: But realistically those 2 problems are not going to be solved any time in the next decade. I have tested 7 large hosting networks only one of them had BCP38. I wonder if it's truly that unrealistic. If we target access networks, it seems impractical target. We have about 40k origin only ASNs and about 7k ASNs which offer transit, who could arguably trivially ACL those 40k peers. If we truly tried, as a community to make deploying these ACLs easy and actively reach out those 7k ASNs and offer help, would it be unrealistic to have ACL deployed to sufficiently large portion of networks to make spoofing impractical/expensive? The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) Count ASN# 1323950 3462 1300938 4134 1270046 8151 1213972 9737 851124 22927 706434 45899 532546 3816 497303 1267 487965 17974 486882 4837 433170 9829 425991 18403 422356 19429 406870 24560 378440 4766 357974 6697 341044 6147 332602 18881 251074 7303 238461 9318 221201 4812 217794 7418 213049 17552 181995 7552 159078 13489 153877 9299 142740 7738 138730 209 120860 8452 118506 46606 117700 14420 107600 17813 101967 36947 98708 6400 93526 36351 92471 4788 89976 9198 88570 11556 81665 9050 81624 27695 80837 13354 80415 701 79032 6332 78164 4808 77937 55430 75800 2554 65618 9394 63992 4713 60380 9808 59274 6057 55177 8400 53862 9269 53266 13285 51620 9329 50822 22833 50320 16276 49847 23752 48998 4780 48278 31549 47195 8167 46484 10299 46270 21844 43439 26599 43211 32475 43048 36444 41688 27668 35448 24863 34160 27866 33068 26496 32166 14754 31656 2379 31450 32613 30641 27699 29225 45951 28804 6389 27836 56040 27406 5617 26758 39501 26454 24940 26175 13999 25736 7018 25482 131090 25478 1221
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On Thu, Aug 8, 2013 at 10:29 AM, Jared Mauch ja...@puck.nether.net wrote: On Aug 1, 2013, at 2:31 AM, Saku Ytti s...@ytti.fi wrote: On (2013-07-31 17:07 -0700), bottiger wrote: But realistically those 2 problems are not going to be solved any time in the next decade. I have tested 7 large hosting networks only one of them had BCP38. I wonder if it's truly that unrealistic. If we target access networks, it seems impractical target. We have about 40k origin only ASNs and about 7k ASNs which offer transit, who could arguably trivially ACL those 40k peers. If we truly tried, as a community to make deploying these ACLs easy and actively reach out those 7k ASNs and offer help, would it be unrealistic to have ACL deployed to sufficiently large portion of networks to make spoofing impractical/expensive? The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) Count ASN# 1323950 3462 1300938 4134 1270046 8151 1213972 9737 ... For the technically clueless among us... what does count refer to in this output? How many times you were able to spoof an address through them? How many different addresses you could spoof through them? How many spoofed packets made it through before being blocked? It's kinda hard to know what the list represents without a bit of explanation around it. ^_^; Thanks! :) Matt
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On Aug 8, 2013, at 1:40 PM, Matthew Petach mpet...@netflight.com wrote: On Thu, Aug 8, 2013 at 10:29 AM, Jared Mauch ja...@puck.nether.net wrote: On Aug 1, 2013, at 2:31 AM, Saku Ytti s...@ytti.fi wrote: On (2013-07-31 17:07 -0700), bottiger wrote: But realistically those 2 problems are not going to be solved any time in the next decade. I have tested 7 large hosting networks only one of them had BCP38. I wonder if it's truly that unrealistic. If we target access networks, it seems impractical target. We have about 40k origin only ASNs and about 7k ASNs which offer transit, who could arguably trivially ACL those 40k peers. If we truly tried, as a community to make deploying these ACLs easy and actively reach out those 7k ASNs and offer help, would it be unrealistic to have ACL deployed to sufficiently large portion of networks to make spoofing impractical/expensive? The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) Count ASN# 1323950 3462 1300938 4134 1270046 8151 1213972 9737 ... For the technically clueless among us... what does count refer to in this output? How many times you were able to spoof an address through them? How many different addresses you could spoof through them? How many spoofed packets made it through before being blocked? It's kinda hard to know what the list represents without a bit of explanation around it. ^_^; Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). If those ASNs are downstream to you, or you are part of that ASN, you can ask for a list of the IPs involved. Either way, if you have 1.2 million hosts, it may be a lot of BCP38 you need to apply. - Jared
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
I noticed that two of my ASNs are on that list for example with low numbers. I can't fathom how as at least one of them has uRPF implemented on any actual interfaces and no downstreams/peers. -Blake On Thu, Aug 8, 2013 at 12:40 PM, Matthew Petach mpet...@netflight.comwrote: On Thu, Aug 8, 2013 at 10:29 AM, Jared Mauch ja...@puck.nether.net wrote: On Aug 1, 2013, at 2:31 AM, Saku Ytti s...@ytti.fi wrote: On (2013-07-31 17:07 -0700), bottiger wrote: But realistically those 2 problems are not going to be solved any time in the next decade. I have tested 7 large hosting networks only one of them had BCP38. I wonder if it's truly that unrealistic. If we target access networks, it seems impractical target. We have about 40k origin only ASNs and about 7k ASNs which offer transit, who could arguably trivially ACL those 40k peers. If we truly tried, as a community to make deploying these ACLs easy and actively reach out those 7k ASNs and offer help, would it be unrealistic to have ACL deployed to sufficiently large portion of networks to make spoofing impractical/expensive? The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) Count ASN# 1323950 3462 1300938 4134 1270046 8151 1213972 9737 ... For the technically clueless among us... what does count refer to in this output? How many times you were able to spoof an address through them? How many different addresses you could spoof through them? How many spoofed packets made it through before being blocked? It's kinda hard to know what the list represents without a bit of explanation around it. ^_^; Thanks! :) Matt
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. This is not the spoofer list, but the list of ASNs with open resolvers. Let me reprocess it. Apologies, corrected data being generated. - Jared On Aug 8, 2013, at 1:29 PM, Jared Mauch ja...@puck.nether.net wrote: The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt )
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On Thu, 08 Aug 2013 12:46:10 -0500, Blake Dunlap said: I noticed that two of my ASNs are on that list for example with low numbers. I can't fathom how as at least one of them has uRPF implemented on any actual interfaces and no downstreams/peers. Most likely, you have places where one host in a /24 or /28 can spoof a packet claiming to be another host in the same subnet, and have the spoofed packet escape into the outside world. There's really no way to stop that unless you get *really* fascist with your edge-host facing routers/switches. pgpDDbPG5qyAq.pgp Description: PGP signature
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On a related note, how are you actually getting this data? What you have said previously ( Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). ) doesn't even make sense. -Blake On Thu, Aug 8, 2013 at 12:51 PM, Jared Mauch ja...@puck.nether.net wrote: Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. This is not the spoofer list, but the list of ASNs with open resolvers. Let me reprocess it. Apologies, corrected data being generated. - Jared On Aug 8, 2013, at 1:29 PM, Jared Mauch ja...@puck.nether.net wrote: The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt )
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
All, Here's the correct list, apologies for the confusion. http://openresolverproject.org/spoofers-20130804-byasn-count.txt Top ASN excerpt: Count ASN 46024 5617 43729 9394 28358 17964 27923 3269 24323 12874 22726 4847 22690 286 1136 21541 6079 20380 20825 11538 17430 10657 7497 17430 10544 4766 9883 7497 9061 3462 8875 38208 8553 7385 8295 4812 7297 11830 7204 7029 7137 3215 6655 6854 6618 4788 6424 17621 5794 53173 5069 8452 4944 9808 4930 6830 4877 38511 4648 4134 4135 2856 3982 9340 3678 6805 3605 38235 3398 17816 3364 9299 3297 9812 3238 15003 3221 9116 3025 4565 On Aug 8, 2013, at 1:51 PM, Jared Mauch ja...@puck.nether.net wrote: Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. This is not the spoofer list, but the list of ASNs with open resolvers. Let me reprocess it. Apologies, corrected data being generated. - Jared On Aug 8, 2013, at 1:29 PM, Jared Mauch ja...@puck.nether.net wrote: The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt )
2013 NANOG Board - Call for Nominations
Dear NANOGers, Hope you are enjoying this great Summer. Following our July 15, 2013 posting ‘‘Announcing the October 2013 NANOG Elections’ which provided a preview into our election process, on behalf of the Board and 2013 Elections Committee, we are pleased to open the Call for Board Member Nominations for the three vacant positions on the Board of Directors. The nomination period starts August 9 and closes September 20, 2013 at 23:59 Pacific Standard Time. If you are nominating another person, please send that person's name and email address to electi...@nanog.org and we will contact them to acknowledge their willingness to stand and will ask them to submit their Declaration of Candidacy Form, found under the2013 Elections Main Menu. If you are nominating yourself, please submit your Declaration of Candidacy Form and email it to electi...@nanog.org. Below is the summary of the Board Member role and a detailed description is viewable on our NANOG website. Position: Board Member Time commitment: Five hours per week (meetings, preparation, consultation) for Members or Eight hours per week (meetings, preparation, consultation) for Officers (Chair, Vice Chair, Secretary, Treasurer). Term:Two years. Maximum of two consecutive terms. Accountability The Board of Directors are collectively accountable to the community, sponsors and other stakeholders. They are accountable for NANOG’s performance in relation to its mission and strategic objectives and for the effective stewardship of financial and human resources. Authority Individual board members have no authority to approve actions by NANOG, to direct staff, or to speak on behalf for NANOG, unless given such authority by the board. Responsibility Board members are responsible for acting in the best long-term interests of the organization and its community and will bring to the task of informed decision-making, a broad knowledge and an inclusive perspective. General Duties Every member of the Board of Directors is expected to do the following: · Be a NANOG member in good standing · Prepare for and attend board meetings every fortnight · Work as a team member and support board decisions · Participate in the review of NANOG’s mission and objectives and the development of a strategic plan · Monitor the performance of the organization in relation to objectives and core values · Approve the budget and monitor financial performance in relation to it · Abide by the by-laws, code of conduct and other policies that apply to the board · Establish, review and monitor policies that guide core operational practices (eg. financial management, human resource management) · Participate in hiring and releasing the Executive Director · Participate in the evaluation of the Executive Director · Participate in the recruitment of new board members · Participate in the evaluation of the board itself · Participate in committee work (liaison) · Appoint Standing committees members · Appoint Ad-Hoc committees members. · Attend two out of every three NANOG conferences · Keep informed about community issues relevant to the mission and objectives of NANOG Qualifications The following are considered key job qualifications: ·Knowledge of the community ·Experience in or willingness to participate in the governance of a non-profit organization ·Demonstrated aptitudes for financial management ·Leadership, outreach and communication skills ·Commitment to organization’s mission and strategic directions ·A commitment of time ·Consensus organizing and openness to learning Removal of a Board Member A Board of Directors member who misses three or more meetings in a row and who does not attend any Board of Directors meetings for three months may be removed. The Board of Directors is an active and engaged component of NANOG. As NANOG continues to evolve, our Board and our Committees will continue to play an increasingly important role in our success. We thank you in advance for becoming NANOG members and taking an active part in our governance. Should you have any questions, please feel free to send the electi...@nanog.org. Best regards Michael K. Smith Vice Chair, NANOG Board of Directors
Re: IPAM
Hi, I'm pretty sure that if 6connect doesn't have an existing tool to import Northstar that they'd work with your client to get it done. +1 on 6connect. Very helpful people there :-) Sander
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On Aug 8, 2013, at 2:07 PM, Blake Dunlap iki...@gmail.com wrote: On a related note, how are you actually getting this data? Sure: https://www.nanog.org/sites/default/files/tue.lightning3.open_resolver.mauch_.pdf I would point you at the streaming archive, but I'm not sure where they went. Perhaps they can post them to Youtube? Anyways, the alternate set of IPs responding is actually increasing over time: http://openresolverproject.org/breakdown-graph2.cgi What you have said previously ( Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). ) doesn't even make sense. Many CPE devices will perform NAT on udp/53 packets received on their WAN interface and forward them to their configured DNS server. Some will just take the source IP and copy it into the packet. Because it comes in on their WAN interface, it will instead of copying the inside NAT address just copy my source IP from the weekly scan and use that. Since it's on the outside, it doesn't copy it's outside IP and put that in, it copies mine. - Jared On Thu, Aug 8, 2013 at 12:51 PM, Jared Mauch ja...@puck.nether.net wrote: Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. This is not the spoofer list, but the list of ASNs with open resolvers. Let me reprocess it. Apologies, corrected data being generated. - Jared On Aug 8, 2013, at 1:29 PM, Jared Mauch ja...@puck.nether.net wrote: The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt )
RE: Strange entries from AS1 in global table
That's correct, I have seen L3 use that for MPLS as recently as a few months ago. -James -Original Message- From: Brad Fleming [mailto:bdfle...@gmail.com] Sent: Thursday, August 08, 2013 7:49 AM To: Humberto Galiza Cc: NANOG Mailing List Subject: Re: Strange entries from AS1 in global table I think Level(3) uses it for at least some L3 MPLS VPN stuff. We peer with that AS for dedicated SIP service transport for example. On Aug 8, 2013, at 5:25 AM, Humberto Galiza humbertogal...@gmail.com wrote: Looking at our routers I can see this: 3549 3356 26114 1 i 12956 1239 23520 23383 1 ? but neither 26114 or 23383 are Brazilian ISP´s. Anyway, I guess it´s probably leaked routes or even use of AS 1 as private one (I don´t think level3 guys are using this AS anymore...). Cheers, Humberto Galiza 2013/8/4 Anurag Bhatia m...@anuragbhatia.com: Hello everyone I was looking at global IPv4 table and saw some strange entries from AS1. As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of Brazil based ISP - Netvip http://bgp.he.net/AS1#_prefixes Looking at any prefix in detail, it seems like there are multiple ASNs announcing same prefix. E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 (Netvip's allocated ASN). Same is true with 177.185.98.0/24, 177.185.98.0/24and so on. http://bgp.he.net/net/177.185.96.0/24 So seems like AS1 acting like a mirror for all announcements of AS52931. To see who exactly gave transit to AS1 by Netvip in Brazil, I checked Oregon and noticed these routes: 3356 3549 16735 52931 1 i Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which seems like a backbone ISP in Brazil) is not filtering these routes further passing to Level3 (AS3549+AS3356). I am curious to know what could be possible reason for an ASN like AS1 acting in exact mirror of AS52931? Could it be a case of internal use of AS1 (assuming it to be private ASN)? May be it's a case of leaked internal routes? Appreciate your time answer. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
Thanks, this is quite interesting. I never would have expected that kind of behavior. -Blake On Thu, Aug 8, 2013 at 3:37 PM, Jared Mauch ja...@puck.nether.net wrote: On Aug 8, 2013, at 2:07 PM, Blake Dunlap iki...@gmail.com wrote: On a related note, how are you actually getting this data? Sure: https://www.nanog.org/sites/default/files/tue.lightning3.open_resolver.mauch_.pdf I would point you at the streaming archive, but I'm not sure where they went. Perhaps they can post them to Youtube? Anyways, the alternate set of IPs responding is actually increasing over time: http://openresolverproject.org/breakdown-graph2.cgi What you have said previously ( Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). ) doesn't even make sense. Many CPE devices will perform NAT on udp/53 packets received on their WAN interface and forward them to their configured DNS server. Some will just take the source IP and copy it into the packet. Because it comes in on their WAN interface, it will instead of copying the inside NAT address just copy my source IP from the weekly scan and use that. Since it's on the outside, it doesn't copy it's outside IP and put that in, it copies mine. - Jared On Thu, Aug 8, 2013 at 12:51 PM, Jared Mauch ja...@puck.nether.net wrote: Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. This is not the spoofer list, but the list of ASNs with open resolvers. Let me reprocess it. Apologies, corrected data being generated. - Jared On Aug 8, 2013, at 1:29 PM, Jared Mauch ja...@puck.nether.net wrote: The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt )
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
On Aug 8, 2013, at 9:13 PM, Blake Dunlap iki...@gmail.com wrote: Thanks, this is quite interesting. I never would have expected that kind of behavior. I've been having trouble getting in touch with the Netgear security group about this, if someone knows how to contact them, I'd appreciate a referral on this topic :) - Jared
