Re: odd hijack
On Thu, 9 Nov 2006, Josh Karlin wrote: Read Joe's PPT. All explained there. Hank Nussbacher http://www.interall.co.il Wouldn't they want to hijack more specifics to spam? I doubt much of that space is going to correctly route for spamming purposes.
Re: Verizon PSTN continued
Centralised switching guarantees QOS! Keep saying it and it might be true! On 11/9/06, Sean Donelan [EMAIL PROTECTED] wrote: On Tue, 7 Nov 2006, Chris L. Morrow wrote: Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not... you'd think they'd have systems monitoring that and trimming down the 'fat'? or can they do that? (legally I mean, sorta like QOS for the phone network I suppose) They can, and do. But SS7 interconnect battles between carriers are about as much fun as peering battles between ISPs, lots of finger pointing and blustering and more lawyers. If you lose SS7 links between carriers, and there is not enough SS7 capacity remaining, the SS7 systems start flapping (the SS7 folks probably use a different term, but it gives the IP folks some idea of what happens). It has happened a few times. I expect the SS7 vendors and protocol wizards are thinking up more clever ways to address it. It has nothing (essentially) to do with the type of calls being made, although high call volumes always make any problem worse. Another time it happened was just before Christmas a few years ago, during peak shopping time and the dialup credit card authorization numbers (and lots of other types of numbers) got jammed up during a SS7 incident as I found out doing my Christmas shopping that afternoon.
BGP Update Report
BGP Update Report Interval: 27-Oct-06 -to- 05-Nov-06 (10 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS13156 17582 2.2% 279.1 -- AS13156 Cabovisao,SA 2 - AS337839110 1.2% 82.8 -- EEPAD 3 - AS156117241 0.9% 67.0 -- Iranian Research Organisation 4 - AS2854 7017 0.9% 200.5 -- ROSPRINT-AS Equant Russia AS 5 - AS154716980 0.9% 58.7 -- SNR-RO SNR - Societatea Nationala de Radiocomunicatii 6 - AS287516801 0.9% 37.0 -- CAUCASUS-NET-AS Caucasus Network Tbilisi, Georgia 7 - AS3602 6718 0.8% 12.7 -- AS3602-RTI - Rogers Telecom Inc. 8 - AS6629 5529 0.7% 83.8 -- NOAA-AS - NOAA 9 - AS812 5348 0.7% 12.6 -- ROGERS-CABLE - Rogers Cable Inc. 10 - AS4621 5171 0.7% 38.3 -- UNSPECIFIED UNINET-TH 11 - AS9121 5108 0.7% 45.2 -- TTNET TTnet Autonomous System 12 - AS346954939 0.6% 89.8 -- E4A-AS E4A Primary AS 13 - AS179744596 0.6% 16.2 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 14 - AS6386 4502 0.6% 17.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 15 - AS141174318 0.6% 18.0 -- Telefonica del Sur S.A. 16 - AS702 4284 0.5% 14.6 -- AS702 MCI EMEA - Commercial IP service provider in Europe 17 - AS4755 4073 0.5% 8.0 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 18 - AS239183945 0.5% 32.1 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS 19 - AS721 3880 0.5% 13.3 -- DISA-ASNBLK - DoD Network Information Center 20 - AS7738 3875 0.5% 31.2 -- Telecomunicacoes da Bahia S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS315942996 0.4%2996.0 -- FORTESS-AS Fortess LLC Network 2 - AS3043 2232 0.3%2232.0 -- AMPHIB-AS - Amphibian Media Corporation 3 - AS392501042 0.1%1042.0 -- COLOPROVIDER-AS Colo Provider 4 - AS34378 648 0.1% 648.0 -- RUG-AS Razguliay-UKRROS Group 5 - AS264601144 0.1% 572.0 -- CERTEGY-INC - CERTEGY INC. 6 - AS1258 557 0.1% 557.0 -- XKL-NET-AS - XKL Systems Corporation 7 - AS18173 529 0.1% 529.0 -- AKU-AS-PK Aga Khan University 8 - AS32225 413 0.1% 413.0 -- MCGRAW-BCM - McGraw Communications 9 - AS146993714 0.5% 412.7 -- BTCBCI - Bloomingdale Communications Inc 10 - AS3944 411 0.1% 411.0 -- PARTAN-LAB - Partan Partan 11 - AS32937 810 0.1% 405.0 -- CAC-FOR-THE-DEAF-AND-HARD-OF-HEARING - Communication Access Center for the Deaf and Hard of Hearing, Inc. 12 - AS34277 397 0.1% 397.0 -- ITSN-AS IT Systems aut-num in Donetsk 13 - AS33188 770 0.1% 385.0 -- SCS-NETWORK-1 - Sono Corporate Suites 14 - AS305172685 0.3% 383.6 -- GREAT-LAKES-COMNET - Great Lakes Comnet, Inc. 15 - AS11904 373 0.1% 373.0 -- ALLENTEL - Allendale Telephone Company 16 - AS41212 314 0.0% 314.0 -- CARCADE Carcade Network Tupolev Plaza 17 - AS31527 286 0.0% 286.0 -- TELEPOL-AS Telepol Security 18 - AS13816 849 0.1% 283.0 -- BLUEBONNET - Bluebonnet Technologies 19 - AS13156 17582 2.2% 279.1 -- AS13156 Cabovisao,SA 20 - AS12671 277 0.0% 277.0 -- SPACENETOL Internet Service Provider TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 194.242.124.0/22 2996 0.3% AS31594 -- FORTESS-AS Fortess LLC Network 2 - 209.140.24.0/242232 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 3 - 203.199.128.0/19 1855 0.2% AS4755 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 4 - 61.0.0.0/8 1424 0.1% AS4678 -- FINE CANON NETWORK COMMUNICATIONS INC. 5 - 217.129.168.0/21 1240 0.1% AS13156 -- AS13156 Cabovisao,SA 6 - 83.98.220.0/23 1042 0.1% AS39250 -- COLOPROVIDER-AS Colo Provider 7 - 217.129.192.0/21959 0.1% AS13156 -- AS13156 Cabovisao,SA 8 - 205.105.128.0/20959 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 9 - 143.81.0.0/21 903 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 10 - 194.42.208.0/20 890 0.1% AS705 -- ALTERNET-AS - UUNET Technologies, Inc. 11 - 217.129.128.0/20889 0.1% AS13156 -- AS13156 Cabovisao,SA 12 - 217.129.48.0/20 868 0.1% AS13156 -- AS13156 Cabovisao,SA 13 - 217.129.112.0/20868 0.1% AS13156 -- AS13156 Cabovisao,SA 14 - 217.129.200.0/21867 0.1% AS13156 -- AS13156 Cabovisao,SA 15 - 217.129.96.0/21 862 0.1% AS13156 -- AS13156 Cabovisao,SA 16 - 217.129.104.0/21862 0.1%
The Cidr Report
This report has been generated at Fri Nov 10 21:40:01 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
03-11-06199409 129843
04-11-06199323 129829
05-11-06199330 129854
06-11-06199273 129854
07-11-06 -1077936760 129854
08-11-06 672037797 129854
09-11-06 -1077937324 129854
10-11-06 134555024 129854
AS Summary
0 Number of ASes in routing system
0 Number of ASes announcing only one prefix
1495 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
0 Largest address span announced by an AS (/32s)
pP. :
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').
--- 10Nov06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 199273 1298546941934.8% All ASes
AS4755 1013 63 95093.8% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS4134 1197 279 91876.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS18566 973 129 84486.7% COVAD - Covad Communications
Co.
AS9498 865 129 73685.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS4323 1027 295 73271.3% TWTC - Time Warner Telecom,
Inc.
AS22773 712 48 66493.3% CCINET-2 - Cox Communications
Inc.
AS19262 735 180 55575.5% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS721858 309 54964.0% DISA-ASNBLK - DoD Network
Information Center
AS7018 1495 972 52335.0% ATT-INTERNET4 - ATT WorldNet
Services
AS6197 1020 506 51450.4% BATI-ATL - BellSouth Network
Solutions, Inc
AS17488 546 45 50191.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS11492 799 299 50062.6% CABLEONE - CABLE ONE
AS19916 565 68 49788.0% ASTRUM-0001 - OLM LLC
AS855537 88 44983.6% CANET-ASN-4 - Aliant Telecom
AS18101 474 26 44894.5% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS17676 500 64 43687.2% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS3602 523 104 41980.1% AS3602-RTI - Rogers Telecom
Inc.
AS4766 703 311 39255.8% KIXS-AS-KR Korea Telecom
AS812423 34 38992.0% ROGERS-CABLE - Rogers Cable
Inc.
AS2386 1121 748 37333.3% INS-AS - ATT Data
Communications Services
AS4812 431 60 37186.1% CHINANET-SH-AP China Telecom
(Group)
AS8151 772 410 36246.9% Uninet S.A. de C.V.
AS6467 401 69 33282.8% ESPIRECOMM - Xspedius
Communications Co.
AS16852 373 55 31885.3% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS15270 477 191 28660.0% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS16814 330 52 27884.2% NSS S.A.
AS9583 953 684 26928.2% SIFY-AS-IN Sify Limited
AS14654 298 30 26889.9% WAYPORT - Wayport
AS17849 429 162 26762.2% GINAMHANVIT-AS-KR hanvit ginam
broadcasting comm.
AS33588 391 125 26668.0% BRESNAN-AS - Bresnan
Communications, LLC.
Total 20941 653514406
Re: odd hijack
the preso link is below, you didnt read it yet.. :) you can hijack any address space providing your route is preferred either because it is more specific, less specific, shorter as-path.. Steve On Thu, Nov 09, 2006 at 10:59:20PM -0700, Josh Karlin wrote: Wouldn't they want to hijack more specifics to spam? I doubt much of that space is going to correctly route for spamming purposes. On 11/9/06, Hank Nussbacher [EMAIL PROTECTED] wrote: On Thu, 9 Nov 2006, Josh Karlin wrote: Here is one that is somewhat the opposite, the AS announced a significant portion of IANA allocated space. Note, they are large blocks and as such probably did not cause much damage because most networks announce more specifics. My question to the community is, what kind of misconfiguration could cause this set of prefixes to be announced? I asked the AS responsible, but have not had a response. Misconfiguration? :-) That's a nice word for spammer. See Joe's PPT at: http://www.uoregon.edu/~joe/maawg8/maawg8.ppt AS29449 is not the problem. It is the upstreams of AS5602 (KPNQwest Italia) and AS286 (KPN) that let this crap leak. -Hank Nussbacher http://www.interall.co.il -- Stephen J. Wilcox BSc (Hons). CCIE #10730 Technical Director, Telecomplete http://www.telecomplete.co.uk/
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Fri, Nov 10, 2006 at 01:25:05AM -0500, Robert Boyle wrote: At 06:58 PM 11/9/2006, you wrote: automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to Since I am the OP, I never said that filtering bogons was a miracle cure all. If we put static bogon filters on customer routers, I would agree that would be stupid and would cause maintenance and routing problems. As an ISP several assignments from formerly bogon blocks, I agree and understand your point. However, we are religious about updating our bogon filters and we never block legitimate traffic or announcements. Bogon filtering is just one thing among many which I think should be done. Following BCP38 and filtering what comes in from customers and transit/peer connections all help to ensure that you aren't part of the problem to the community or to your own clients. The original poster who I replied to stated that it appeared that some traffic of unknown origin on a private address was being routed across his network between routers and he didn't have any routes for that network in his routing tables. My response was that those announcements and traffic should be filtered at his edge. This turned into a thread about whether filtering was a good thing or not which in my mind is absurd. However, if you run a network and want to accept traffic from bogon and RFC1918 space over your customer, peering, and transit connections then that's your problem. I just choose to not make it mine. We may be talking at cross purposes... BGP filtering using bogon lists affects the routes you receive and hence whether or not you are willing to send traffic TO that space. If you want to not 'accept traffic FROM bogon and RFC1918 space' then you need to apply acls or rpf. My issue with BGP filtering is primarily related to manually built filters, there is evidence that this practice is harmful. Whether automatically built filters is a good idea is up to you, the current feeling seems to be yes altho personally I dont implement it. WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space. I still would advise tho that there is a lot of address space in use but ot announced on the internet, add to that the use of RFC1918 on internal network links and the potential to break things such as pmtu by dropping icmps is real. Steve
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. I think there is a terminology problem here. People think that bogons means bogus routes. From that they infer that bogus routes should be filtered and use the Cymru feed because it seems to be a no-brainer. The problem arises because the Cymru feed only contains the low-hanging fruit. It only refers to address ranges that *might* be bogus and which are easy to identify. The problem is that if you pick this fruit, it soon goes rotten and you end up filtering address ranges which are in use and almost certainly not bogus. If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed. But at the present time, such a feed does not exist. Also, I think that anyone contemplating creating a new feed should give some thought to what they are doing. It would be very useful to have a feed or database which can assign various attributes to address ranges. When there is only one possible attribute, bogon, then the meaning of the attribute gets stretched and the feed becomes useless. But if there are many attributes such as UNALLOCATED, UNASSIGNED, DOS-SOURCE, SPAM-SOURCE, RIR-REGISTERED then it starts to look interesting. Some networks might like to filter based on several attributes, others will just filter those with the DOS-SOURCE attribute. Obviously, it would require lots of cooperation for some of these such as UNASSIGNED, but perhaps the Internet needs to move towards more cooperation between network operators. --Michael Dillon
Re: odd hijack
My question to the community is, what kind of misconfiguration could cause this set of prefixes to be announced? 11.0.0.0/8 12.0.0.0/7 121.0.0.0/8 122.0.0.0/7 124.0.0.0/7 126.0.0.0/8 128.0.0.0/3 etc ... This looks to me like some large multinational leaked their internal announcements to an ISP. It is not unusual for large companies to use random unregistered /8 blocks in their internal networks. There are all kinds of applications that need to talk across networks which do not need any Internet connectivity or any direct connectivity to general use workstations. This network traffic would normally be hidden inside some kind of VPN on the same infrastructure as other corporate traffic. So to answer your question, first look for all the ways that a misconfiguration could allow routing information to leak out of some flavor of VPN. --Michael Dillon
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Fri, 10 Nov 2006, [EMAIL PROTECTED] wrote: If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed. But at the present time, such a feed does not exist. http://www.cymru.com/BGP/bogon-rs.html Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING NORTH UTSIRE: SOUTHERLY VEERING WESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. HIGH. RAIN THEN SHOWERS. MODERATE OR GOOD.
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space. Your comment implies that ACLs are static and must be configured manually. In this day and age of automated systems, that is no longer true. Anyone who wants to can easily implement dynamic ACLs. They will be slightly less dynamic than a routing protocol, but ACLs do not have to be manually configured and do not have to be static. Of course, on some hardware ACLs have a significant CPU impact, but that is less of a factor than it used to be. --Michael Dillon
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed. But at the present time, such a feed does not exist. http://www.cymru.com/BGP/bogon-rs.html That is not a feed of routes that are known to be bogus. That is a feed of routes that use addresses which have not been allocated by IANA to an RIR. There are many bogus routes that are not included in the Cymru feed. For instance, RIR address ranges that have not yet been allocated ISP address ranges that have not yet been assigned Assigned address ranges that are not announced by the assignee. Address ranges from which a high percentage of the traffic is SPAM, i.e. a network owned by spammers. I am arguing that it is better to start with a database that allows several attributes, both negative and positive, to be associated with address ranges. Then build a feed from that, in fact, allow the user to specify which attributes they want in their feed. One size fits all just doesn't work. --Michael Dillon
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Fri, Nov 10, 2006 at 01:18:02PM +, [EMAIL PROTECTED] wrote: WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space. Your comment implies that ACLs are static and must be configured manually. In this day and age of automated systems, that is no longer true. Anyone who wants to can easily implement dynamic ACLs. They will be slightly less dynamic than a routing protocol, but ACLs do not have to be manually configured and do not have to be static. Of course, on some hardware ACLs have a significant CPU impact, but that is less of a factor than it used to be. for the purpose of scope tho we have to imagine this is a large ISP looking at every one of its border links to peers and transits given that, your options for suitable deployments are a lot more limited Steve
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Fri, Nov 10, 2006 at 12:54:28PM +, [EMAIL PROTECTED] wrote: The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. I think there is a terminology problem here. People think that bogons means bogus routes. From that they infer that bogus routes should be filtered and use the Cymru feed because it seems to be a no-brainer. The problem arises because the Cymru feed only contains the low-hanging fruit. It only refers to address ranges that *might* be bogus and which are easy to identify. The problem is that if you pick this fruit, it soon goes rotten and you end up filtering address ranges which are in use and almost certainly not bogus. If there were some way to have a feed of real bogons, i.e. address prefixes that are *KNOWN* to be bogus at the point in time they are in the feed, that would be useful for filtering. And it would likely be a best practice to use such a feed. But at the present time, such a feed does not exist. Also, I think that anyone contemplating creating a new feed should give some thought to what they are doing. It would be very useful to have a feed or database which can assign various attributes to address ranges. When there is only one possible attribute, bogon, then the meaning of the attribute gets stretched and the feed becomes useless. But if there are many attributes such as UNALLOCATED, UNASSIGNED, DOS-SOURCE, SPAM-SOURCE, RIR-REGISTERED then it starts to look interesting. Some networks might like to filter based on several attributes, others will just filter those with the DOS-SOURCE attribute. how about PORN-SOURCE, COMMUNIST-SOURCE, DEMOCRACY-SOURCE, TERRORIST-SOURCE, RIGHT-WING-CHRISTIAN-SOURCE, COURT-ISSUED-LIBEL-CASE-SOURCE be careful before you open such a pandoras box... will this scale? who will want to use it? can it be exploited? what sort of liability do you take on by becoming responsible for policing the Internet? Steve
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
how about PORN-SOURCE, COMMUNIST-SOURCE, DEMOCRACY-SOURCE, TERRORIST-SOURCE, RIGHT-WING-CHRISTIAN-SOURCE, COURT-ISSUED-LIBEL-CASE-SOURCE be careful before you open such a pandoras box... The box was opened a long time ago. In an Internet context, there are many email blacklists which apply various different criteria for inclusion, therefore, they are essentially publishing different attributes. In a social context, freedom of religion is a long-accepted principle and various religions publish lists of literature that is either acceptable or unacceptable. If a network operator finds a business case for supplying service only to right wing organizations and blocking network traffic from communist sources then what is wrong with that? The principle of the Internet is that network operators run private networks and set their own policies independent of regulators and governments. will this scale? The fact that the database has multiple attributes to assign to address ranges makes it more likely to scale. who will want to use it? People who find some value in dynamically filtering Internet traffic based on a trusted source for filters. can it be exploited? Virtually anything can be exploited. Smart network operators do not hardwire their routers to a 3rd-party BGP feed. Instead they pull that feed into their operational support systems where it can raise alarms so that a human being can decide whether to stop or start filtering a particular range. Or else they make some kind of 2-party binding contract with SLAs and penalties such as a transit contract or a peering agreement. what sort of liability do you take on by becoming responsible for policing the Internet? Who said anything about policing the Internet? This is all about identifying address ranges who source various kinds of traffic that some network operators do not wish to transit their networks. Every network operator has an AUP for their own customers and peers. This merely extends that to 3rd parties who wish to transit the network. --Michael Dillon
RE: link between Sprint and Level3 Networks is down in Chicago
Charlie said: I would be interested in comparing notes with anybody else affected by the issue - or if anybody has heard an actual explanation from Sprint/L3. Things started to clear up for us at around 1443 Central, so it wasn't too long after I posted my original inquiry to the list. By 1500 Central it seemed to be fully functional. Over at http://www.internetpulse.net our experience seemed to be reflected in that the Network Availability metric for the Sprint/L3 intersection started creeping back up from 80%. This morning at 0830 I got a phone call from the BSAC folks at Sprint, who said it was exclusively a routing issue within L3. When I pressed for details all I got was the same answer. Make of that what you will. -JFO
Re: odd hijack
Wouldn't they want to hijack more specifics to spam? no. see nick feamster's work, and the lightning talk i proxied for him in dallas. randy
Re: odd hijack
Wouldn't they want to hijack more specifics to spam? no. see nick feamster's work, and the lightning talk i proxied for him in dallas. randy Right, you might want to announce less specifics so that you go unnoticed and then you can spam from blocks not in use. I'm just somewhat surprised that they would announce /3's, /6's, and /7's and be so incredibly obvious about it rather than actually be covert and just announce a few more specifics that likely noone would notice. But I guess at this point they're still not being caught so why worry. Josh
Re: odd hijack
On Fri, Nov 10, 2006 at 05:55:40AM -1000, Randy Bush wrote: Wouldn't they want to hijack more specifics to spam? no. see nick feamster's work, and the lightning talk i proxied for him in dallas. Here are the links from our observations on this, from our Feb NANOG talk: http://www.nanog.org/mtg-0606/pdf/nick-feamster.pdf and our SIGCOMM paper: http://sigcomm06.stanford.edu/discussion/showpaper.php?paper_id=28%22 Cheers, Nick
Re: odd hijack
On Fri, Nov 10, 2006 at 11:01:02AM +, [EMAIL PROTECTED] wrote: the preso link is below, you didnt read it yet.. :) you can hijack any address space providing your route is preferred either because it is more specific, less specific, shorter as-path.. Slides 13-15 of our Feb 2006 NANOG talk show examples of this and describe the motivation. The technique us also described in detail in our SIGCOMM paper, along with several other observations about why doing things like looking at uncommon origin ASes to detect a determined hijacker is unlikely to ever be successful at detecting a malicious hijack (as opposed to a misconfiguration). -Nick
Re: odd hijack
On Fri, Nov 10, 2006 at 07:20:10AM +0200, Hank Nussbacher wrote:
AS29449 is not the problem. It is the upstreams of AS5602 (KPNQwest
Italia) and AS286 (KPN) that let this crap leak.
In fact, it may not even be the immediate upstreams. In our paper, we
describe specific examples where it's very hard to track exactly who's at
fault, because so much of the AS path appears to be forged. See finding #5 in
the excerpt below.
I include the most germane excerpt from the paper below, for people's
convenience. btw, Randy Bush helped us understand this technique a bit better
and coined the phrase spectrum agility.
...
We have called this technique ``spectrum agility'' because it allows a
spammer the flexibility to use a wide variety of IP addresses within a
very large block from which to send spam. The large IP address block
allows the mail relays to ``hop'' between a large number of IP
addresses, thereby evading IP-based filtering techniques like DNSBLs.
Judging from Figure~\ref{fig:dnsbls} and our analysis in
Section~\ref{sec:dnsbls}, the technique seems to be rather effective.
As an added benefit, route announcements for shorter IP prefixes (\ie,
larger blocks of IP addresses) are less likely to be blocked by ISPs'
route filters than route announcements or hijacks for longer prefixes.
Upon further inspection, we also discovered the following interesting
features: (1)~the IP addresses of the mail relays sending this spam are
widely distributed across the IP address space; (2)~the IP addresses
from which we see spam in this address space typically appear only once;
(3)~on February 6, 2006, attempts to contact the mail relays that we
observed using this technique revealed that that roughly 60-80\% of
these hosts were not reachable by {\tt traceroute}; (4)~many of the IP
addresses of these mail relays were located in allocated, albeit
unannounced and unused IP address space; and (5)~many of the AS paths
for these announcements contained reserved (\ie, to-date unallocated AS
numbers), suggesting a possible attempt to further hamper traceability
by forging elements of the AS path.
...
-Nick
Re: The Cidr Report
cidr-report writes: Recent Table History Date PrefixesCIDR Agg 03-11-06199409 129843 [...] 10-11-06 134555024 129854 Growth of the global routing table really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon.
Re: The Cidr Report
Indeed -- it apears to have flaked out a bit this (IETF) week. :-) Date PrefixesCIDR Aggregated 04-11-06 199323 129829 05-11-06 199330 129854 06-11-06 199273 129854 07-11-06 -1077937252 129854 08-11-06 -1077936760 129854 09-11-06 672037797 129854 10-11-06 -1077937324 129854 11-11-06 134555024 129854 - ferg -- Simon Leinen [EMAIL PROTECTED] wrote: cidr-report writes: Recent Table History Date PrefixesCIDR Agg 03-11-06199409 129843 [...] 10-11-06 134555024 129854 Growth of the global routing table really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
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 [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 11 Nov, 2006 Analysis Summary BGP routing table entries examined: 202898 Prefixes after maximum aggregation: 110235 Unique aggregates announced to Internet: 98574 Total ASes present in the Internet Routing Table: 23617 Origin-only ASes present in the Internet Routing Table: 20571 Origin ASes announcing only one prefix:9916 Transit ASes present in the Internet Routing Table:3046 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 5 Unregistered ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 1632337484 Equivalent to 97 /8s, 75 /16s and 126 /24s Percentage of available address space announced: 44.0 Percentage of allocated address space announced: 60.9 Percentage of available address space allocated: 72.3 Total number of prefixes smaller than registry allocations: 102613 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:44828 Total APNIC prefixes after maximum aggregation: 18271 Prefixes being announced from the APNIC address blocks: 42407 Unique aggregates announced from the APNIC address blocks:18544 APNIC Region origin ASes present in the Internet Routing Table:2751 APNIC Region origin ASes announcing only one prefix:774 APNIC Region transit ASes present in the Internet Routing Table:413 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 268148384 Equivalent to 15 /8s, 251 /16s and 158 /24s Percentage of available APNIC address space announced: 83.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:101382 Total ARIN prefixes after maximum aggregation:59857 Prefixes being announced from the ARIN address blocks:74626 Unique aggregates announced from the ARIN address blocks: 28255 ARIN Region origin ASes present in the Internet Routing Table:11124 ARIN Region origin ASes announcing only one prefix:4234 ARIN Region transit ASes present in the Internet Routing Table:1031 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 309186464 Equivalent to 18 /8s, 109 /16s and 207 /24s Percentage of available ARIN address space announced: 68.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 96/6, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 41229 Total RIPE prefixes after maximum aggregation:27278 Prefixes being announced from the RIPE address blocks:38059 Unique aggregates announced from the RIPE address blocks: 25596 RIPE Region origin ASes present in the Internet Routing Table: 8751 RIPE Region origin ASes announcing only one prefix:4619 RIPE Region transit ASes present in
Charter.net contact?
Any Charter.net mail admins around? I'd love to hear from one. Regards, Steve
Re: odd hijack
I'm just somewhat surprised that they would announce /3's, /6's, and /7's and be so incredibly obvious about it if it was incredibly obvious, why did it take us so long to see it? and no, please let's not all have a i saw it first contest. randy
Re: Charter.net contact?
S. Ryan wrote: Any Charter.net mail admins around? I'd love to hear from one. Regards, Steve I got some contacts there that I had to use when there mail servers were not accepting mail. Hold on let me dig them up, I think they're on my laptop. I'll follow up with you in ~20 - 40 minutes. -Bill -- Bill Sehmel - [EMAIL PROTECTED] -- 1-206-242-2743 Systems Administrator, HopOne Internet Corp. SEA2 NOC Bandwidth full range of carrier/web host colo + networking services: http://www.hopone.netASN 14361
Re: Call for Presentations - NANOG 39 - Toronto
Steve, February 4-7? That would be Sunday through Wednesday... is this correct? Did I miss something at the last NANOG meeting? :-) Thanks, - ferg -- Steve Feldman [EMAIL PROTECTED] wrote: The North American Network Operators' Group (NANOG) will hold its 39th meeting February 4-7, 2007, in Toronto, Canada. The meeting will be co-hosted by the Toronto Internet Exchange and Teleglobe, a VSNL International company. [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Call for Presentations - NANOG 39 - Toronto
It's the new normal Monday-Wednesday schedule, with a newcomers reception and community meeting Sunday afternoon. We started doing that at the winter meeting, but couldn't in St. Louis due to ARIN's schedule. Steve On Nov 11, 2006, at 6:49 AM, Fergie wrote: Steve, February 4-7? That would be Sunday through Wednesday... is this correct? Did I miss something at the last NANOG meeting? :-) Thanks, - ferg -- Steve Feldman [EMAIL PROTECTED] wrote: The North American Network Operators' Group (NANOG) will hold its 39th meeting February 4-7, 2007, in Toronto, Canada. The meeting will be co-hosted by the Toronto Internet Exchange and Teleglobe, a VSNL International company. [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
