Re: [NANOG] Questions about NETCONF
On May 15, 2008, at 10:28 PM, 袁智辉 wrote: How is the state of arts of NETCONF (RFC 4741) protocol? Is there any Network Management System Deployed which is base on NETCONF? I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it. Do you think security products (like Firewall, IDS/IPS and Security Operation Centre) can benefit from NETCONF? I believe any network device can benefit from netconf. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Questions about NETCONF
I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it. does this not imply that all devices would need to be semantically congruent? if so, is this realistic? randy ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] BGP Update Report
BGP Update Report Interval: 14-Apr-08 -to- 15-May-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9498 111266 1.1% 92.0 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - AS958379859 0.8% 65.6 -- SIFY-AS-IN Sify Limited 3 - AS614067771 0.7% 98.5 -- IMPSAT-USA - ImpSat USA, Inc. 4 - AS17974 64466 0.6% 141.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS10796 59308 0.6% 77.1 -- SCRR-10796 - Road Runner HoldCo LLC 6 - AS238659219 0.6% 41.3 -- INS-AS - ATT Data Communications Services 7 - AS29571 58039 0.6% 397.5 -- CITelecom-AS 8 - AS475553254 0.5% 32.2 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 9 - AS815151646 0.5% 41.6 -- Uninet S.A. de C.V. 10 - AS26829 49478 0.5% 49478.0 -- YKK-USA - YKK USA,INC 11 - AS651747810 0.5% 71.4 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 12 - AS453846765 0.5% 9.6 -- ERX-CERNET-BKB China Education and Research Network Center 13 - AS24731 46456 0.5% 573.5 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 14 - AS17488 46283 0.5% 40.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 15 - AS638945657 0.5% 28.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 16 - AS919844710 0.4% 90.0 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 17 - AS701842522 0.4% 28.7 -- ATT-INTERNET4 - ATT WorldNet Services 18 - AS11060 41810 0.4% 319.2 -- NEO-RR-COM - Road Runner HoldCo LLC 19 - AS11492 39948 0.4% 32.6 -- CABLEONE - CABLE ONE 20 - AS647838498 0.4% 40.0 -- ATT-INTERNET3 - ATT WorldNet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS26829 49478 0.5% 49478.0 -- YKK-USA - YKK USA,INC 2 - AS42787 28944 0.3%9648.0 -- MMIP-AS MultiMedia IP Ltd. 3 - AS286467633 0.1%7633.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 4 - AS309296586 0.1%6586.0 -- HUTCB Hidrotechnical Faculty - Technical University 5 - AS429235848 0.1%5848.0 -- PLK-AS PLK AS Number 6 - AS190174606 0.0%4606.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 7 - AS193344250 0.0%4250.0 -- SPORTLINE-DBC - SPORTLINE 8 - AS403594036 0.0%4036.0 -- SOUTHEASTERNMILLS-ROME - Southeastern Mills, Inc. 9 - AS23082 18344 0.2%3668.8 -- MPHI - Michigan Public Health Institute 10 - AS16466 17912 0.2%3582.4 -- AVAYA AVAYA 11 - AS329963575 0.0%3575.0 -- AGRIBANK-STPAUL - AgriBank, FCB 12 - AS299103572 0.0%3572.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 13 - AS353243570 0.0%3570.0 -- ECH-WILL-AS E.C.H. Will 14 - AS181316230 0.1%3115.0 -- IR3 NTT Communications Corporation 15 - AS9122 3022 0.0%3022.0 -- TECHNOELECTROSERVIS-AS Technoelektroservis Ltd. 16 - AS112784675 0.1%2337.5 -- NINTENDO - Nintendo Of America inc. 17 - AS447302278 0.0%2278.0 -- ALFAGOMMA Alfa Gomma s.p.a. 18 - AS343782202 0.0%2202.0 -- RUG-AS Razgulay Group 19 - AS369751883 0.0%1883.0 -- CBA-AS 20 - AS278926976 0.1%1744.0 -- Universidad del Zulia TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 125.23.208.0/20 63377 0.6% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 12.108.254.0/24 49478 0.5% AS26829 -- YKK-USA - YKK USA,INC 3 - 193.33.184.0/23 28860 0.3% AS42787 -- MMIP-AS MultiMedia IP Ltd. 4 - 221.128.192.0/18 26161 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 5 - 84.23.100.0/2422302 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 6 - 221.135.80.0/24 17595 0.2% AS9583 -- SIFY-AS-IN Sify Limited 7 - 118.95.56.0/2417095 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 213.91.175.0/24 15855 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - 203.63.26.0/2410131 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 10 - 201.77.80.0/20 7633 0.1% AS28646 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 11 - 89.4.131.0/24 7148 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 12 - 64.201.128.0/207026 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 13 - 135.10.4.0/24 6849 0.1% AS16466 --
[NANOG] The Cidr Report
This report has been generated at Fri May 16 21:14:57 2008 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
09-05-08265828 167071
10-05-08266024 167271
11-05-08265860 167432
12-05-08265840 167382
13-05-08266035 167641
14-05-08266197 44301
15-05-08 71701 168206
16-05-08265972 166150
AS Summary
28316 Number of ASes in routing system
11925 Number of ASes announcing only one prefix
4885 Largest number of prefixes announced by an AS
AS4538 : ERX-CERNET-BKB China Education and Research Network
Center
88359936 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - 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').
--- 16May08 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 265829 1662119961837.5% All ASes
AS4538 4885 868 401782.2% ERX-CERNET-BKB China Education
and Research Network Center
AS4755 1636 260 137684.1% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS6389 1857 590 126768.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS9498 1162 69 109394.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS4323 1421 571 85059.8% TWTC - Time Warner Telecom,
Inc.
AS22773 949 139 81085.4% CCINET-2 - Cox Communications
Inc.
AS11492 1218 470 74861.4% CABLEONE - CABLE ONE
AS19262 903 168 73581.4% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS8151 1215 490 72559.7% Uninet S.A. de C.V.
AS1785 1017 316 70168.9% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS17488 1064 376 68864.7% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS18101 679 123 55681.9% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS6478 945 397 54858.0% ATT-INTERNET3 - ATT WorldNet
Services
AS2386 1418 890 52837.2% INS-AS - ATT Data
Communications Services
AS7011 1086 617 46943.2% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS18566 1044 584 46044.1% COVAD - Covad Communications
Co.
AS4766 877 420 45752.1% KIXS-AS-KR Korea Telecom
AS22047 566 128 43877.4% VTR BANDA ANCHA S.A.
AS17676 508 74 43485.4% GIGAINFRA BB TECHNOLOGY Corp.
AS6197 1029 610 41940.7% BATI-ATL - BellSouth Network
Solutions, Inc
AS855577 168 40970.9% CANET-ASN-4 - Bell Aliant
AS7018 1417 1013 40428.5% ATT-INTERNET4 - ATT WorldNet
Services
AS6140 610 209 40165.7% IMPSAT-USA - ImpSat USA, Inc.
AS4668 668 268 40059.9% LGNET-AS-KR LG CNS
AS8103 580 183 39768.4% STATE-OF-FLA - Florida
Department of Management
Services - Technology Program
AS7545 497 117 38076.5% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS9443 462 84 37881.8% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS3602 455 79 37682.6% AS3602-RTI - Rogers Telecom
Inc.
AS4808 519 158 36169.6% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Re: [NANOG] [NANOG-announce] NANOG Room Block @ Marriott Brooklyn Bridge
NANOG 43 Meeting Attendees, Re: NANOG Room Block @ Marriott Brooklyn Bridge If you are holding a reservation at the group rate and need to cancel, please let me know. I would like to take over any cancelled reservation so the room can be reassigned to another meeting attendee, and not go back into the hotel's general inventory for resale at the prevailing rate. If you need a room, please send me your check in/check out dates and phone number. I will let you know if a cancelled room becomes available. Carol Wadsworth NANOG/Merit Network ___ NANOG-announce mailing list [EMAIL PROTECTED] http://mailman.nanog.org/mailman/listinfo/nanog-announce ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Routing table for BGP
Your questions depend on several details specific to your organization, which you haven't really devulged. There are several decent books on the subject which I recommend that you invest in. see: * ISBN-10:* 0321127005 *ISBN-10:* 0596002548 http://www.oreilly.com/catalog/bgp/chapter/ch06.html -- this is a chapter from the second book which should wet your appetite a bit. Regards, --Justin devang patel wrote: Hi, I would like to know what route should i accept from internet full or partial? if Partial then what routes should i accept? and how many route does my router have if i will go for Partial routing table? actually I am trying to understand it by concept... my organization is small but I want to know if it is large organization or small provider then what kind of routes do i need in my routing table? regards Devang Patel ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Questions about NETCONF
Randy Bush writes: [in response to John Payne [EMAIL PROTECTED]:] I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it. does this not imply that all devices would need to be semantically congruent? if so, is this realistic? Personally I don't think it is. The way that configuration is structured is something that at least some vendors use to differentiate themselves from each other. (Though other vendors make a point of being compatible with some industry standard CLI.) So if you think that configurations in NETCONF should be similar to the native configuration language, that doesn't bode well for industry-wide standardization of a NETCONF configuration data model. It might still be possible to have a common NETCONF data model, but then that would probably be quite different from the (all) native configuration languages; much in the same way as SNMP MIBs are (structurally) different from how information is presented at the CLI. Personally I'm not sure that this would be a very useful outcome, because there would necessarily be a large lag between when features are implemented (with a native CLI to configure them of course) and when they can be configured through NETCONF. Maybe the best we can shoot for is this: * A common language to describe parts of NETCONF configuration. The newly chartered IETF NETMOD working group[1] is working on this. Vendors can then describe their specific NETCONF data models using this language, and tool writers can use these descriptions to generate code for applications that want to manipulate device configurations. * Common data models for certain well-understood parts of NETCONF configuration. This could include simple atomic things such as how to write an IP address or a prefix in (NETCONF) XML, or configuration of standardized protocols such as OSPF, IPFIX etc. The problem is how well will this support migration from vendor-specific configuration to standardized configuration - which, as I said, is always bound to lag far behind. And even if/when an aspect of a configuration model (let's say for OSPF) is standardized, vendors are bound to extend that model to support not-yet-standardized extensions (e.g. sub-second timers, BFD). This will be another challenge to support. (But there are smart people working on this :-) -- Simon. [1] http://www.ietf.org/html.charters/netmod-charter.html ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Routing table for BGP
Hi, I would like to know what route should i accept from internet full or partial? if Partial then what routes should i accept? and how many route does my router have if i will go for Partial routing table? actually I am trying to understand it by concept... my organization is small but I want to know if it is large organization or small provider then what kind of routes do i need in my routing table? Hi, If its only 1 provider, then probably taking just default route is necessary. If you have 2, then it depends on your setup. I prefer to always take full routes from upstreams, as long as there are good communities within that feed. This way I can vary what I accept or don't accept without the need to constantly contact the upstream. If not, then I have to fiddle more on my end, but I always keep the control. I personally run 2 routers (Ok, switches with routing code, so my memory footprint is severely limited) each with a link to a provider. I ask for full routes PLUS default route. Internally, I discard /24's on both links, and pref up the communities like customer and send them over to the other router with the default route. Saves me alot of memory, plus gives me alot of control. Tuc/TBOH ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Routing table for BGP
The nice thing about NANOG is that we have YEARS of on-line Video training to help you get up to speed. 1. Go to http://www.nanog.org/subjects.html (Index of Talks) 2. Look for materials on BGP. 3. Have fun learning from the best. My suggestion would be to watch last NANOG's BGP Tutorial. The nice thing about this is that you can E-mail the speaker to get clarifications. TO NANOG Community - We should really be pointed these FAQs to the resources/tools we've invested in building. I don't know whose idea it was to VOD everything, but it is an vast untapped store house of knowledge. -Original Message- From: devang patel [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 7:16 AM To: [EMAIL PROTECTED] Subject: [NANOG] Routing table for BGP Hi, I would like to know what route should i accept from internet full or partial? if Partial then what routes should i accept? and how many route does my router have if i will go for Partial routing table? actually I am trying to understand it by concept... my organization is small but I want to know if it is large organization or small provider then what kind of routes do i need in my routing table? regards Devang Patel ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Routing table for BGP
On Fri, May 16, 2008 at 11:00 AM, Barry Raveendran Greene [EMAIL PROTECTED] wrote: The nice thing about NANOG is that we have YEARS of on-line Video training to help you get up to speed. 1. Go to http://www.nanog.org/subjects.html (Index of Talks) 2. Look for materials on BGP. 3. Have fun learning from the best. My suggestion would be to watch last NANOG's BGP Tutorial. The nice thing about this is that you can E-mail the speaker to get clarifications. TO NANOG Community - We should really be pointed these FAQs to the resources/tools we've invested in building. I don't know whose idea it was to VOD everything, but it is an vast untapped store house of knowledge. I think there is a nanog-wiki that Lynda was poking at last even?? Maybe making sure there's a searchable form thingy there for the VOD catalog? -Chris ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
Kai Chen wrote: Hi, here is a quick question. 1. Beside public peering in IXP and private peering between two dedicated ASes, are there any other interconnection models in the current Internet? There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT. 2. How does private peering implement, just a router from each AS and a link inbetween? Do they have multi-access in one peering location? I mean one router from an AS peer with two/more routers from another AS? you'll find that the details vary between entities. some bi-lateral relationships are going to require peering in more than one location, require a minimum ammount of redundancy etc. depends on how business critical the relationship is, how much traffic is being exchanged, the sized of the networks involved etc. Cheers, ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
2008/5/16 Joel Jaeggli [EMAIL PROTECTED]: Kai Chen wrote: Hi, here is a quick question. 1. Beside public peering in IXP and private peering between two dedicated ASes, are there any other interconnection models in the current Internet? There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT. I don't know if the 3rd party you mentioned is the IXP? 2. How does private peering implement, just a router from each AS and a link inbetween? Do they have multi-access in one peering location? I mean one router from an AS peer with two/more routers from another AS? you'll find that the details vary between entities. some bi-lateral relationships are going to require peering in more than one location, require a minimum ammount of redundancy etc. depends on how business critical the relationship is, how much traffic is being exchanged, the sized of the networks involved etc. Sure, two ASs may peer with each other at multiple locations, I do want to know in each of these peering location, if there exist multi-access between these two ASes. Cheers, ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] Fixed Orbit
Anyone have any contacts at Fixed Orbit or know anything about their setup? We have one peer that doesn't show in Fixed Orbit's tables. The peer has been online for 5 months so I doubt that the lack of reflection is due to staleness. I've emailed Fixed Orbit but received no response. -- Morgan A. Miskell Carolina Internet 704-643-8330 x206 The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] df upload
have someone trying to get files to me from mexico d.f. their home site can not survive the uploads (a few tens of megabytes). anyone know someone in df with reliable bandwidth they could share a bit? randy ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] BCP Muni WiFI?
Deepak, Excellent question. I'm currently deploying a test environment for a large scale wifi network. You can see more project info at wiki.socalwifi.org and at socalwifi.blogspot.com. I am documenting everything we are doing and will have a Blog post up soon regarding our kerberos/radius/VPN deployment and how we load test/scale it. i have yet to see any existing information on the back end components specifically related to muni wifi. I would imagine standard documentation/white papers related to scaling a large enterprise wifi network apply. Charles --Original Message-- From: Deepak Jain To: nanog list ReplyTo: [EMAIL PROTECTED] Sent: May 15, 2008 2:21 PM Subject: [NANOG] BCP Muni WiFI? Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? Thanks in advance, DJ ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog Sent via BlackBerry from T-Mobile ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive)
Hi folks, As everybody is a big fan of securing their networks against foreign attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that is, not IPv4, they all come from a single IPv6 /13 though, which is what they apparently asked for in the beginning, at least that was the rumor, well they got what they wanted. I've recorded it into GRH as a single /13 though, as that is what it is, and I am not going to bother whois'ing and entering the 14 separate entries there, as that is useless, especially as they will most likely never appear in the global routing tables anyway. Depending on your love for the US, you might want to add special rules in your network to be able to easily detect Cyber Attacks and other such things towards that address space, to be able to better serve your country, may that be the US or any other country for that matter. I am of course wondering why ARIN gave 1 organization 14 separate /22's, even though they are recorded exactly the same, just different prefixes and netnames and it is effectively one huge /13. They could easily have been recorded as that one /13, it is not like eg Canada (no other countries that fall under ARIN now is there) will get a couple of the chunks of remaining space in between there. By assigning them separate /22's, they effectively are stating that it is good to fragment the address space and by having them recorded in whois, also that announcing more specifics from that /13 is just fine. The other fun question is of course what a single organization has to do with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which cover 2.251.799.813.685.248 /64's which is a number that I can't even pronounce. According to Wikipedia the US only has a mere population of 304,080,000, that means that every US citizen can get a 1000+ /48's from their DoD, thus maybe every nuclear warhead and every bullet is getting their own /48 or something to be able to justify for that amount of address space. At least this gives the opportunity to hardcode that block out of hardware if you want to avoid it being ever used by the publicly known part of the US DoD. I wouldn't mind seeing the request form that can justify this amount of address space though, must be a lot of fun. Now back to your regular NANOG schedule Greets, Jeroen (who will hide himself in a nice Swiss nuclear bunker till the flames are all gone ;) 1) http://en.wikipedia.org/wiki/United_States which points to: http://www.census.gov/population/www/popclockus.html ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] BCP Muni WiFI?
On Thu, May 15, 2008 at 4:21 PM, Deepak Jain [EMAIL PROTECTED] wrote: Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? BCP #58,271,432--which basically states Don't, comes highly recommended. Instead, investigate your nearest .16e or evdo rev. A reseller. In the case of .16e, most available APN's are built around user and transport/transit abstractions, assuming shared-facilities, virtual providers, etc. The equipment used in both is a far cry from anything 802.11. p. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Fixed Orbit
Morgan, Fixed Orbit is broken, I doubt it has ever worked and I wouldn't use it for anything meaningful. Keith O'Neill Pando Networks Morgan Miskell wrote: Anyone have any contacts at Fixed Orbit or know anything about their setup? We have one peer that doesn't show in Fixed Orbit's tables. The peer has been online for 5 months so I doubt that the lack of reflection is due to staleness. I've emailed Fixed Orbit but received no response. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] BCP Muni WiFI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Interesting comment Paul. However, 16e and evdo are a bit heavy with infrastructure to support mobility. Before giving that answer, you may want to ask Deepak if he NEEDS mobility Chris On 16 May 2008, at 10.23, Paul Wall wrote: On Thu, May 15, 2008 at 4:21 PM, Deepak Jain [EMAIL PROTECTED] wrote: Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? BCP #58,271,432--which basically states Don't, comes highly recommended. Instead, investigate your nearest .16e or evdo rev. A reseller. In the case of .16e, most available APN's are built around user and transport/transit abstractions, assuming shared-facilities, virtual providers, etc. The equipment used in both is a far cry from anything 802.11. p. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog - --- 李柯睿 Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB67593B -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJILcx7AAoJEGmx2Mt/+Iw/20UIAJjNOQ7JSbE8/iqGbuFZPEVX AvQ/eRPHT6BhLXNSg5WZiL4aQcDeLhkMYwhpJTMkslHg5hveQHN/pUQB9pkMeqCZ jffRbiKDzypaDf8q/Rx1vORO/bnQ4R27AfeKDc75Z07YewdBa9PKZz2EgsjVHQmp FNDq9dVDWAI+scK3BFNge+QNeXatYUf0gP+LnRmNaPu+KZBThjD+Wmd6FWlfmuRa GxvTOrESrbhRxrnF128B5RXa/GBohduiql1jrU0phb6w2a/NJbd+a4yvHANZpBHk fwU3BrZKLixRtOOM3uA4ZPgliTUO/lD4tpW8SEWnvluhRe1tTIrmgf4qjxit5gA= =z83n -END PGP SIGNATURE- ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] 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 17 May, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 255996 Prefixes after maximum aggregation: 127048 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 124142 Total ASes present in the Internet Routing Table: 28207 Prefixes per ASN: 9.08 Origin-only ASes present in the Internet Routing Table: 24602 Origin ASes announcing only one prefix: 11444 Transit ASes present in the Internet Routing Table:3605 Transit-only ASes present in the Internet Routing Table: 80 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (39375) 13 Prefixes from unregistered ASNs in the Routing Table: 25568 Unregistered ASNs in the Routing Table:1888 Number of 32-bit ASNs allocated by the RIRs: 47 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:787 Number of addresses announced to Internet: 1852593056 Equivalent to 110 /8s, 108 /16s and 83 /24s Percentage of available address space announced: 50.0 Percentage of allocated address space announced: 61.4 Percentage of available address space allocated: 81.4 Percentage of address space in use by end-sites: 71.9 Total number of prefixes smaller than registry allocations: 123367 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:43195 Total APNIC prefixes after maximum aggregation: 13464 APNIC Deaggregation factor:3.21 Prefixes being announced from the APNIC address blocks: 55719 Unique aggregates announced from the APNIC address blocks:23792 APNIC Region origin ASes present in the Internet Routing Table:1944 APNIC Prefixes per ASN: 28.66 APNIC Region origin ASes announcing only one prefix:547 APNIC Region transit ASes present in the Internet Routing Table:354 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 349020128 Equivalent to 20 /8s, 205 /16s and 159 /24s Percentage of available APNIC address space announced: 80.0 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/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, 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:107932 Total ARIN prefixes after maximum aggregation:59258 ARIN Deaggregation factor: 1.82 Prefixes being announced from the ARIN address blocks:86932 Unique aggregates announced from the ARIN address blocks: 34225 ARIN Region origin ASes present in the Internet Routing Table:11816 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix:4615 ARIN Region transit ASes present in the Internet Routing Table:1043 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 358062720 Equivalent to 21 /8s, 87 /16s and 154 /24s Percentage of available ARIN address space announced: 73.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607,
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Not to address the political issues here (which are deep, wide, and WAY too much of a black-hole), remember, that the DoD is not a single organization from a networking perspective. There are a number of different organizations within that structure, all of which may, or may not, want to announce separately, maintain their own external links, etc. Those boundaries can be on a service level (USAF vs USN), geographical level (Southern Command vs. Northern Command), etc. My guess is that they don't want to be tied to only announcing a single /13. Each of those organizations is bigger than a lot of service providers out there... As for why so many addresses - consider a networked ship (where everything has an address), soldier (each soldier having one or more addresses), battlefield sensors, etc. With stateless autoconf, that can add up fairly quickly (depending on network topology). Lastly, If you honestly think that any entity (government or non- government) would launch an offensive cyber-attack from their own address space... never mind Chris On 16 May 2008, at 10.58, Dorn Hetzel wrote: Perhaps it is an attempt to make their address space so sparsely populated that it's close to impossible to find a host without knowing it's address in the first place? On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar [EMAIL PROTECTED] wrote: Hi folks, As everybody is a big fan of securing their networks against foreign attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that is, not IPv4, they all come from a single IPv6 /13 though, which is what they apparently asked for in the beginning, at least that was the rumor, well they got what they wanted. I've recorded it into GRH as a single /13 though, as that is what it is, and I am not going to bother whois'ing and entering the 14 separate entries there, as that is useless, especially as they will most likely never appear in the global routing tables anyway. Depending on your love for the US, you might want to add special rules in your network to be able to easily detect Cyber Attacks and other such things towards that address space, to be able to better serve your country, may that be the US or any other country for that matter. I am of course wondering why ARIN gave 1 organization 14 separate / 22's, even though they are recorded exactly the same, just different prefixes and netnames and it is effectively one huge /13. They could easily have been recorded as that one /13, it is not like eg Canada (no other countries that fall under ARIN now is there) will get a couple of the chunks of remaining space in between there. By assigning them separate /22's, they effectively are stating that it is good to fragment the address space and by having them recorded in whois, also that announcing more specifics from that /13 is just fine. The other fun question is of course what a single organization has to do with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which cover 2.251.799.813.685.248 /64's which is a number that I can't even pronounce. According to Wikipedia the US only has a mere population of 304,080,000, that means that every US citizen can get a 1000+ /48's from their DoD, thus maybe every nuclear warhead and every bullet is getting their own /48 or something to be able to justify for that amount of address space. At least this gives the opportunity to hardcode that block out of hardware if you want to avoid it being ever used by the publicly known part of the US DoD. I wouldn't mind seeing the request form that can justify this amount of address space though, must be a lot of fun. Now back to your regular NANOG schedule Greets, Jeroen (who will hide himself in a nice Swiss nuclear bunker till the flames are all gone ;) 1) http://en.wikipedia.org/wiki/United_States which points to: http://www.census.gov/population/www/popclockus.html ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog - --- 李柯睿 Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB67593B -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJILc81AAoJEGmx2Mt/+Iw/0HEH/1HZmv1nsNRpz1sqjMJwy0kr O68VCagg7tNfRLq/ErY8lOkxcVsAp0R6urZN8kJwt59MBcd1Yat8BxqayfXcbrx4 m/y361FKjEt8HpBBcS5EiHftjojD2aWczlinJuGL97koDw390ozuZhXLvui27JsE Zh2LHdLrya2ZKMkfL2/mLc7J1C0CiuMvflDVCURG8c+aG17O+aH8csTbxHzStoH4 U0lbxH6hvOHVtQdaHa4JKtZD6zdUIn4quZnwnyPO7mop9005h/W4GRIqB4fUQMGB Jk+8bo5ArTxIlceunhLhbUhMAphF7RaABNKBxsUrgc4nqQVVCV8fOCbyvOr6rTA= =z0uG -END PGP SIGNATURE-
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but nottotally consecutive)
OH, You mean like putting a sniper in a bunch of trees. They know that tactic well. :) Robert D. Scott [EMAIL PROTECTED] Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 -Original Message- From: Dorn Hetzel [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 1:59 PM To: Jeroen Massar Cc: NANOG list Subject: Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but nottotally consecutive) Perhaps it is an attempt to make their address space so sparsely populated that it's close to impossible to find a host without knowing it's address in the first place? On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar [EMAIL PROTECTED] wrote: Hi folks, As everybody is a big fan of securing their networks against foreign attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that is, not IPv4, they all come from a single IPv6 /13 though, which is what they apparently asked for in the beginning, at least that was the rumor, well they got what they wanted. I've recorded it into GRH as a single /13 though, as that is what it is, and I am not going to bother whois'ing and entering the 14 separate entries there, as that is useless, especially as they will most likely never appear in the global routing tables anyway. Depending on your love for the US, you might want to add special rules in your network to be able to easily detect Cyber Attacks and other such things towards that address space, to be able to better serve your country, may that be the US or any other country for that matter. I am of course wondering why ARIN gave 1 organization 14 separate /22's, even though they are recorded exactly the same, just different prefixes and netnames and it is effectively one huge /13. They could easily have been recorded as that one /13, it is not like eg Canada (no other countries that fall under ARIN now is there) will get a couple of the chunks of remaining space in between there. By assigning them separate /22's, they effectively are stating that it is good to fragment the address space and by having them recorded in whois, also that announcing more specifics from that /13 is just fine. The other fun question is of course what a single organization has to do with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which cover 2.251.799.813.685.248 /64's which is a number that I can't even pronounce. According to Wikipedia the US only has a mere population of 304,080,000, that means that every US citizen can get a 1000+ /48's from their DoD, thus maybe every nuclear warhead and every bullet is getting their own /48 or something to be able to justify for that amount of address space. At least this gives the opportunity to hardcode that block out of hardware if you want to avoid it being ever used by the publicly known part of the US DoD. I wouldn't mind seeing the request form that can justify this amount of address space though, must be a lot of fun. Now back to your regular NANOG schedule Greets, Jeroen (who will hide himself in a nice Swiss nuclear bunker till the flames are all gone ;) 1) http://en.wikipedia.org/wiki/United_States which points to: http://www.census.gov/population/www/popclockus.html ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] BCP Muni WiFI?
I thought that I had seen an open source muni wifi cookbook somewhere, but I haven't been able to find it. This might be useful to drill down into. http://www.ctnbayarea.org/community-wireless Regards Marshall On May 16, 2008, at 12:24 PM, [EMAIL PROTECTED] wrote: Deepak, Excellent question. I'm currently deploying a test environment for a large scale wifi network. You can see more project info at wiki.socalwifi.org and at socalwifi.blogspot.com. I am documenting everything we are doing and will have a Blog post up soon regarding our kerberos/radius/VPN deployment and how we load test/scale it. i have yet to see any existing information on the back end components specifically related to muni wifi. I would imagine standard documentation/white papers related to scaling a large enterprise wifi network apply. Charles --Original Message-- From: Deepak Jain To: nanog list ReplyTo: [EMAIL PROTECTED] Sent: May 15, 2008 2:21 PM Subject: [NANOG] BCP Muni WiFI? Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? Thanks in advance, DJ ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog Sent via BlackBerry from T-Mobile ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive)
On 16/05/2008 20:15 Christopher LILJENSTOLPE wrote: My guess is that they don't want to be tied to only announcing a single /13. Each of those organizations is bigger than a lot of service providers out there... Since when do you have to announce only the same size prefix as your allocation? -- Colin Alston ~ http://www.karnaugh.za.net/ To the world you may be one person, to one person you may be the world ~ Rachel Ann Nunes. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] BCP Muni WiFI?
Deepak Jain wrote: Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? http://wndw.net/ Thanks in advance, DJ ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totallyconsecutive)
The other fun question is of course what a single organization has to do with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which cover 2.251.799.813.685.248 /64's which is a number that I can't even pronounce. Perhaps the DARPA initiative regarding having each mine have its own network address (so it can communicate and hop around) is closer than we think. http://www.theregister.co.uk/2003/04/11/the_selfhealing_selfhopping_landmine/ (The animation content has moved to: http://www.darpa.mil/sto/smallunitops/shm/index.htm#) Perhaps next each round of ammo will have its own IPv6 address. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totallyconsecutive)
Perhaps next each round of ammo will have its own IPv6 address. Perhaps every round will (or anti-personnel) mine will be stamped with its V6 address so you can track its shrapnel for all time? IPv6 ensures uniqueness, there is no requirement for universal, perpetual connectivity. DJ ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totallyconsecutive)
Brings a whole new meaning to packet fragmentation :) On Fri, May 16, 2008 at 5:05 PM, Deepak Jain [EMAIL PROTECTED] wrote: Perhaps next each round of ammo will have its own IPv6 address. Perhaps every round will (or anti-personnel) mine will be stamped with its V6 address so you can track its shrapnel for all time? IPv6 ensures uniqueness, there is no requirement for universal, perpetual connectivity. DJ ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] Hibernia Atlantic Outage
I'm hearing reports of a Hibernia outage on one of their fiber paths, with downtime approaching a week. Does anybody know what's going on there, and when they expect to have service restored? Which provider(s) are impacted? Was their diverse path impacted as well (as with prior Hibernia outages), or just this path? Paul ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] AIM security
#include sys/nanog/page.h An AIM security engineer/admin is requested. Please contact off-list. (*) I'll settle for an AOL security type with a buddy who works in AIM. It's all good at this point. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] [EMAIL PROTECTED] invalid now (Was Re: Microsoft.com PMTUD black hole?)
On Wed, 07 May 2008 12:24:57 -0700 Nathan Anderson/FSR [EMAIL PROTECTED] wrote: Here is a brief update on the situation: snip Team. They, in turn, forwarded my message on to [EMAIL PROTECTED], which generated a ticket # for me and is, as I understand it, the e-mail address I was looking for in the first place (leads to their network/system people). Doesn't look like it unfortunately. I've just tried to use this email address to advise them of some routing issues we're having with new APNIC IP ranges (114/8 specifically), and I've just got: -- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mail server after RCPT TO:[EMAIL PROTECTED]: host mailb.microsoft.com [131.107.115.215]: 550 5.1.1 User unknown -- Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] BCP Muni WiFI?
On Fri, May 16, 2008 at 11:03:39AM -0700, Christopher LILJENSTOLPE wrote: Interesting comment Paul. However, 16e and evdo are a bit heavy with infrastructure to support mobility. Before giving that answer, you may want to ask Deepak if he NEEDS mobility He needs mobility. If he doesn't know that, it means he hasn't done his due diligence properly. Cheers, -- jra On 16 May 2008, at 10.23, Paul Wall wrote: On Thu, May 15, 2008 at 4:21 PM, Deepak Jain [EMAIL PROTECTED] wrote: Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? BCP #58,271,432--which basically states Don't, comes highly recommended. Instead, investigate your nearest .16e or evdo rev. A reseller. In the case of .16e, most available APN's are built around user and transport/transit abstractions, assuming shared-facilities, virtual providers, etc. The equipment used in both is a far cry from anything 802.11. -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] RackMount DC to AC Inverters
Hello all, I have some equipment going into a Telco Co which only offers battery backup on it's DC power plant. Most of the equipment that is already moving into that facility is AC powered, so I am looking for advice on rackmount DC inverters. Looking for something that can accommodate inverting enough power to load a 30 AMP 110 circuit, preferably something that has N+1 redundancy.. I'm not finding a lot of options on Google, so I figured that I would ask here... ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] IOS rootkits
At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS rootkit. skip below for the news item itself. We've had discussions on this before, here and elsewhere. I've been heavily attacked on the subject of considering router security as an issue when compared to routing security. I have a lot to say about this, looking into this threat for a few years now and having engaged different organizations within Cisco on the subject in the past. Due to what I refer to as an NDA of honour I will just relay the following until it is officially public, then consider what should be made public, including: 1. Current defense startegies possible with Cisco gear 2. Third party defense strategies (yes, they now exist) 2. Cisco response (no names or exact quotes will likely be given) 3. A bet on when such a rootkit would be public, and who won it (participants are.. relevant people). From: http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html A security researcher has developed malicious rootkit software for Cisco's routers, a development that has placed increasing scrutiny on the routers that carry the majority of the Internet's traffic. Sebastian Muniz, a researcher with Core Security Technologies, developed the software, which he will unveil on May 22 at the EuSecWest conference in London. Gadi Evron. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] [EMAIL PROTECTED] valid (was Re: [EMAIL PROTECTED] invalid now)
Hi, On Sat, 17 May 2008 10:20:06 +0930 Mark Smith [EMAIL PROTECTED] wrote: On Wed, 07 May 2008 12:24:57 -0700 Nathan Anderson/FSR [EMAIL PROTECTED] wrote: snip -- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mail server after RCPT TO:[EMAIL PROTECTED]: host mailb.microsoft.com [131.107.115.215]: 550 5.1.1 User unknown -- Somebody from Microsoft kindly contacted me off list, the email address is [EMAIL PROTECTED] - note the removed s. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] IOS rootkits
Gadi, Please try to keep the self-promotion to a minimum, and come back when you have meaningful data to share with operators. Examples would include a list of affected platforms and code revisions, as well as preventative measures. Thank you, Paul On Fri, May 16, 2008 at 9:06 PM, Gadi Evron [EMAIL PROTECTED] wrote: At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS rootkit. skip below for the news item itself. We've had discussions on this before, here and elsewhere. I've been heavily attacked on the subject of considering router security as an issue when compared to routing security. I have a lot to say about this, looking into this threat for a few years now and having engaged different organizations within Cisco on the subject in the past. Due to what I refer to as an NDA of honour I will just relay the following until it is officially public, then consider what should be made public, including: 1. Current defense startegies possible with Cisco gear 2. Third party defense strategies (yes, they now exist) 2. Cisco response (no names or exact quotes will likely be given) 3. A bet on when such a rootkit would be public, and who won it (participants are.. relevant people). From: http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html A security researcher has developed malicious rootkit software for Cisco's routers, a development that has placed increasing scrutiny on the routers that carry the majority of the Internet's traffic. Sebastian Muniz, a researcher with Core Security Technologies, developed the software, which he will unveil on May 22 at the EuSecWest conference in London. Gadi Evron. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] IOS rootkits
On Fri, 16 May 2008, Paul Wall wrote: Gadi, Please try to keep the self-promotion to a minimum, and come back when you have meaningful data to share with operators. Examples would include a list of affected platforms and code revisions, as well as preventative measures. Name on the door, money to be sent via paypal. I will sign my playgirl cover for 5 USD each. This is operational, and it is about me saying na na na na na, na na na na na na to a discussion from two years ago. I have every intention to gloat, but I will keep it to a minimum. Yes? Gadi. On Fri, May 16, 2008 at 9:06 PM, Gadi Evron [EMAIL PROTECTED] wrote: At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS rootkit. skip below for the news item itself. We've had discussions on this before, here and elsewhere. I've been heavily attacked on the subject of considering router security as an issue when compared to routing security. I have a lot to say about this, looking into this threat for a few years now and having engaged different organizations within Cisco on the subject in the past. Due to what I refer to as an NDA of honour I will just relay the following until it is officially public, then consider what should be made public, including: 1. Current defense startegies possible with Cisco gear 2. Third party defense strategies (yes, they now exist) 2. Cisco response (no names or exact quotes will likely be given) 3. A bet on when such a rootkit would be public, and who won it (participants are.. relevant people). From: http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html A security researcher has developed malicious rootkit software for Cisco's routers, a development that has placed increasing scrutiny on the routers that carry the majority of the Internet's traffic. Sebastian Muniz, a researcher with Core Security Technologies, developed the software, which he will unveil on May 22 at the EuSecWest conference in London. Gadi Evron. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
Kai Chen wrote: There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT. I don't know if the 3rd party you mentioned is the IXP? Some IXPs have MLPA (MultiLateral Peering Agreements) where some or all of the participants agree to connect to a route server (usually with it's own AS) and exchange routes this way. It's reasonably common around AsiaPac - all the peering fabrics in Australia are MLPA for example, but I can think of optional examples in the USA (eg. Any2) that have it as an option or places like HKIX which have an MPLA which is mandatory for Hong Kong prefixes. This doesn't stop you doing bilateral as well across the same fabrics. MLPA works well in certain environments, especially where the major IP transit providers in a country won't peer, but rivalries tend to mean that a neutral (or fairly neutral) 3rd party can provide the routing part (this is pretty much what happened in Australia). It's convienient for content providers - they can hook up to one route server and often pickup half of the people on the exchange without having to spend ages negotiating with small networks who often don't have the technical know how or don't have the BGP experience, or indeed the smaller networks themselves as they can connect to an exchange and at least guarantee enough data to justify doing so. It gets more complex as some networks then become bigger and become transit providers and don't like customers sending routes to them via a peering fabric etc. Which is why, with a much more diverse range of networks and no one player dominating people the transit game (eg. in the USA, Western Europe) that MLPA isn't common. Some MLPAs give you some control over routing (eg. don't send my prefixes to AS), but a lot don't. Regards, Matthew ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
On 17/05/2008, at 5:05 PM, Matthew Moyle-Croft wrote: Some MLPAs give you some control over routing (eg. don't send my prefixes to AS), but a lot don't. If you really need to, you can get a similar effect by using ASPATH poisoning; just prepend your AS paths with the ASes you don't want those prefixes hitting. Similar, not identical, so may not work for you how you want. Googling around finds some explanation of it here: http://ispcolumn.isoc.org/2005-08/as1.html Nothing really about how it works in a MLPA IXP though. -- Nathan Ward ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] peering between ASes
Nathan Ward wrote: If the foreign AS really wants to send you routes that way, they can do it regardless of how you stop your advertisements being accepted by/ reaching them. We're hardly talking high security here. ip route prefix netmask 1.1.1.1 works a treat. I'm not quite sure of your point Nathan. That'd stop connectivity which isn't usually the point - especially if the issue is point (2) below. MLPAs are disliked for two main reasons that I've been able to discern. (1) Lack of control Because of the lack of direct relationships with the other networks you can get some fairly odd routing behaviours which gives suboptimal performance when you meet at multiple MLPAs in a theatre - leading to difficulty in doing traffic engineering. From traffic flows, to wierdness caused by people advertising prefixes inconsistently to transit and peering and blaming IOS bugs for it sigh. (2) Transit customers using an MLPA to not pay for traffic to your network A fair point - but, if they weren't a customer then you might be paying to get their traffic or they would be sending it that way anyway. MMC ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
