- NANOG - lists.nanog.org

2005 Wiretap Report (CALEA)
by Hannigan, Martin 09 May '05

09 May '05

2004 Wiretap report came out 4 May. http://www.govtech.net/magazine/channel_story.php?channel=3&id=93846 Summary: 1700+ intercepts (punch list aggregate). The word VoIP or Internet does not appear anywhere in the 250+ page report. Gambling and Narcotics remain #1 reasons for a lawful order. Terrorism is usually handled FISA avenue, which are secret and not reported publicly. The official FBI document can be found here: http://www.askcalea.net/docs/2004wiretap.pdf -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com

1 0

New UK Operators Forum
by Neil J. McRae 09 May '05

09 May '05

Hello, There has been a new Operators Forum setup in the UK. Please visit: http://www.ukif.org.uk/category.php?catid=44 For more details - we are hoping to open up the governance and have a strong UK operator focus within this group as the UK has lacked this. Regards, Neil

1 0

The evolution of NANOG
by McPherson, Michael 09 May '05

09 May '05

For some time there have been extensive discussions, both in person and via email, concerning the future of NANOG. A dedicated group of individuals (including many of you) has assembled a detailed proposal for NANOG's evolution, a proposal which lays out a number of important ideas. Merit staff are very grateful for the well-informed and constructive work put forth by the NANOG community. We at Merit are in agreement with most of the proposed changes, although there are a few points which we feel require further discussion. In this message I would like to outline Merit's reaction to these proposals and propose some next steps for discussion via email and at the next NANOG meeting in Seattle. As you will see below, our intention is to move forward with these changes over the summer. The first change you will see is one of financial transparency. Beginning with the Seattle meeting, Merit will provide an update on NANOG finances and operations at each meeting. Look for this presentation at every future NANOG meeting; it will take place during the Sunday Special Community Meeting in Seattle. Information will also be posted on nanog.org. We support the formation of a Steering Committee which will provide overall guidance for NANOG operations, appoint the Program Committee, and appoint the mailing list administrator panel. The Steering Committee would consist of six members elected by the NANOG community and one appointed by Merit. We propose that an election process be developed and that the first Steering Committee be elected during the summer of 2005, to begin serving by the Fall NANOG meeting. We support the formation of a Program Committee appointed by the Steering Committee. Our experience leads us to believe that a larger committee will be better able to handle the heavy workload, so we suggest that the Program Committee consist of 16 members (plus one member appointed by Merit). A smooth transition from the current committee to a new one is critical to ensure the success of upcoming meetings. We propose that the current Program Committee continue as presently constituted through the Fall NANOG meeting (except that the three open positions would be filled through appointment by the current committee after an open nomination process). This will allow time for the Steering Committee to be elected and to appoint a new Program Committee. In order to provide continuity and preserve institutional memory of the programming process, half (or more, at the discretion of the Steering Committee) of the members of the first reconstituted Program Committee would be selected from among those current Program Committee members willing to continue service, and the remainder would be new appointments from the community at large. We propose that Steve Feldman continue his capable leadership as Program Committee chair for the first year to help the new committee get established. We recommend that a member of the Steering Committee serve ex officio on the Program Committee, and that the chair of the Program Committee serve ex officio on the Steering Committee. These liaison roles will help ensure that the activities of the two groups are coordinated. We also support the change to mailing list administration, a change already partially implemented. We propose three panel members appointed by the Steering Committee and one appointed by Merit. We seek further discussion on the subject of membership. We at Merit believe that NANOG's success is due in no small part to its informality, an informality which mirrors other technical activities related to the Internet. We believe that addition of a paid membership category will dilute the influence of those who make the effort and take the time to participate in NANOG's main activity, the meetings. We propose that eligibility to vote in NANOG elections be determined solely by registration for NANOG meetings. We look forward to discussing this question in Seattle. Finally, although NANOG is a community of professionals, it is also a Merit business activity and not a separate organization. Merit accepts the risks, both financial and otherwise, created by NANOG. Merit staff are responsible first to Merit's Board of Directors for these financial and risk issues. In order to exercise our responsibility to our Board we must retain final authority over NANOG operations and finances, including representing NANOG to other organizations, negotiating and executing agreements with vendors, and selecting hosts and sites. We do not expect this to be a problem in practice, however, as we intend to work with the new Steering Committee and Program Committee on the presumption that the members of the NANOG community know best what they need from NANOG. We are confident that the goals of community guidance and transparency can be achieved without abrogating our responsibility to Merit's Board. You can read a draft of a proposed new NANOG Charter and action plan at http://www.nanog.org/evolution.html. You will also find a link to the most recent NANOG-reform draft bylaws document for reference. We have adopted considerable language from that document, into which so much effort was put. We thank those who provided that foundation and have participated in the discussion so far, and we encourage everyone to participate in the continuing evolution of NANOG. We are excited about moving NANOG into its future. See you at the NANOG Futures session in Seattle on Tuesday, 17 May. Mike --------------------------------------------------------------------- Michael R. McPherson, Interim President and CEO Merit Network, Inc. | mcpherson(a)merit.edu 1000 Oakbrook Dr., Suite 200 | 734-764-9430 Ann Arbor, MI 48104-6794 | FAX: 734-647-3185 http://www.merit.edu http://www.umich.edu/~mcpherso Scheduling: Gayle Terkeurst, 734-764-8450, gturkey(a)merit.edu ---------------------------------------------------------------------

1 0

Google Web Accelerator
by Vicky Rode 09 May '05

09 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, Did anyone catch this? Has anyone experienced any issues and if so, what steps did you take to address this? http://google.blognewschannel.com/index.php/archives/2005/05/05/much-contro… http://consumingexperience.blogspot.com/2005/05/google-web-accelerator-gwa-… http://www.searchenginejournal.com/index.php?p=1676 According to Google Blogoscoped (see below), the download page has been shut down because they can't handle the load. http://blog.outer-court.com/archive/2005-05-08-n20.html regards, /vicky -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCf6hJpbZvCIJx1bcRAsSiAKC1hRB4epeMef3FAxeC9/dSbfju9gCfSASO OUOZb1US1CLLZ8w/W5n1lnc= =v32F -----END PGP SIGNATURE-----

1 0

Re: google.com outage?
by Fergie (Paul Ferguson) 09 May '05

09 May '05

Sounds plausable, reasonable. - ferg -- Chris Keladis <chris(a)cmc.optus.net.au> wrote: Just a guess, but perhaps with www.google.com returning NXDOMAIN the gethostby* functions tried variations and ended up resolving sites like www.google.com.net which inadvertantly sent people to the spoof site. Seems plausible to me, anyway. Cheers, Chris.

3 2

Re: anycast and ddos
by Hank Nussbacher 08 May '05

08 May '05

At 01:38 AM 07-05-05 +0000, Christopher L. Morrow wrote: I scanned my Telescope report of 3,382 spoofed DDOS attacks last week (May 1-7) and could not find any listed for 216.168.229.0/24, worldnic.com, netsol.com or AS6245. -Hank >worldnic.com. 86400 IN NS ns1.netsol.com. >worldnic.com. 86400 IN NS ns2.netsol.com. >worldnic.com. 86400 IN NS ns3.netsol.com. > >;; ADDITIONAL SECTION: >ns1.netsol.com. 86400 IN A 216.168.229.228 >ns2.netsol.com. 86400 IN A 216.168.229.229 >ns3.netsol.com. 86400 IN A 216.168.229.229 > >why have 3 records and 2 ips? odd. You'd think they would have more ips in >that /21 or other /24's to allocate from, just in case they had to >jettison 1 address which was getting pounded :( (not that these were >getting attacked per-say, but still) > > > [0] - as it seems that the ddos sources were ip address > > spoofed (which is why the service still worked for > > tcp), i owe paul an apology for downplaying the > > immediacy of the need for source address filtering. > > > >It's also not clear that the sources were spoofed, if as Patrick says they >put in a riverhead(s) (which isn't too far fetched) the normal mode for >'protection' of DNS is to: >1) truncate >2) rate-limit - and cache (I think it caches atleast, I know it will go >into proxy mode and rate-limit) > >truncate forces TCP which allows RHG to verify the source address is >really asking to chat, rate-limit function keeps 'bad actors' from >beatting the hell out of the protected resource. > >So, without more info from NetSol (seems not to be forthcoming?) about the >mix of attack traffic (which the RHG will provide) it's hard to state >definitively that the attack was 'mostly spoofed' :(

2 2

ot: gilat (spaceband, starband, deterministic) contacts
by Eric Brunner-Williams in Portland Maine 08 May '05

08 May '05

howdy, if anyone from gilat (or its northamerican downstreams) is on-list, i'd appreciate a contact. tia, eric

1 0

Re: Google DNS problems?!?
by Fergie (Paul Ferguson) 08 May '05

08 May '05

Well, Matthew, my boy, it appears to have been more than a simple spyware incident on a Mac or two. If you're not part of the solution.... - ferg -- "Matthew S. Hallacy" <poptix(a)poptix.net> wrote: On Sun, May 08, 2005 at 02:18:19AM +0000, Fergie (Paul Ferguson) wrote: > > > Does anyone else think that its a bit odd that if it were simply > "DNS problems" that a redirect for www.google.com would end up > at a location which provided this: All of the "hack" evidence is from people looking at a whois query and fretting over: Server Name: GOOGLE.COM.SUCKS.FIND.CRACKZ.WITH.SEARCH.GULLI.COM IP Address: 80.190.192.24 Registrar: KEY-SYSTEMS GMBH Whois Server: whois.rrpproxy.net Referral URL: http://www.key-systems.net Server Name: GOOGLE.COM.HAS.LESS.FREE.PORN.IN.ITS.SEARCH.ENGINE.THAN.SECZY.COM IP Address: 209.187.114.130 Registrar: INNERWISE, INC. D/B/A ITSYOURDOMAIN.COM Whois Server: whois.itsyourdomain.com Referral URL: http://www.itsyourdomain.com We've been over this before, whois queries also return nameservers, which people take advantage of. > http://img179.echo.cx/img179/7959/googlehacked7to.jpg > > [or] > > http://img241.echo.cx/img241/6208/googlemsn3lp.png > > Seems more than simple "DNS problems" to me. > > I hate being played like an idiot.... > > - ferg Wow, one person being redirected to a competitors site, ever heard of spyware? (Yes, even on a Mac) -- Matthew S. Hallacy FUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203

3 2

D�j� Vu
by Fergie (Paul Ferguson) 08 May '05

08 May '05

Wikipedia: The term déjà vu (French: "already seen", also called promnesia) describes the experience of feeling that one has witnessed or experienced a new situation previously. Fergie: http://fergdawg.blogspot.com/2005/05/some-thoughts-on-how-to-succeed-or-not… - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Routing issues Washington DC area
by Fergie (Paul Ferguson) 08 May '05

08 May '05

Depech Mode - Policy of Truth. Well, thanks for the update, but I certainly hope that this "incident" doesn't get glossed over, euphemized, or simply down-played into non-existence like the Network Solutions problems (earlier) did. I'm still waiting for a rational explanation for that one, and all I've seen is bullsh#t. I won't settle for ludicrous euphemisms of what really happened. Nor should any rational, technically inclined engineer. These problems need to be identified, examined technically, and then, perhaps, we can revisit the technical issues which affect all of us. Having said that, this appeared to clearly be more than a simple "glitch" -- and I'd like to see it explained in the sprirt of truthfulness, openess, and the Tao of the 'net. We can't shadow-dance with half-truths, but we can fix real problems when they are acknowledged. Personally, I'm kind of feeling like a mushroom right now -- fed a bunch of sh#t and kept in the dark. - ferg -- Mark Owen <mr.markowen(a)gmail.com> wrote: Everything is back up now. Guess it was a router glitch somewhere to compliment Google's DNS issue. On 5/7/05, Jonathan M. Slivko <jonathan(a)slivko.org> wrote: > Looks OK to me (from Verizon DSL in NY): > > Traceroute to (64.112.229.131) > 1 * (10.32.19.1) 20 ms 22 ms 22 ms > 2 * (130.81.11.161) 22 ms 22 ms 22 ms > 3 so-6-0-0-0.BB-RTR2.NY325.verizon-gni.net (130.81.18.90) 22 ms 22 > ms 22 ms > 4 so-6-0-0-0.BB-RTR2.NY60.verizon-gni.net (130.81.7.201) 22 ms 24 > ms 22 ms > 5 so-2-0-0-0.PEER-RTR1.NY60.verizon-gni.net (130.81.4.214) 24 ms 22 > ms 22 ms > 6 jfk-edge-20.inet.qwest.net (65.116.172.85) 22 ms 22 ms 22 ms > 7 jfk-core-01.inet.qwest.net (205.171.230.14) 22 ms 22 ms 22 ms > 8 stl-core-01.inet.qwest.net (205.171.5.81) 94 ms 122 ms 94 ms > 9 egn-core-01.inet.qwest.net (205.171.5.126) 100 ms 100 ms 100 ms > 10 eug-edge-02.inet.qwest.net (205.171.150.18) 102 ms 100 ms 100 ms > 11 * (207.109.243.74) 100 ms 100 ms 102 ms > 12 64-112-224-3-ips-eug-or-core02.tcpipservices.net (64.112.224.3) > 116 ms 116 ms 118 ms > 13 64-112-227-69-ips-eug-or-lb01-2.tcpipservices.net > (64.112.227.69) 116 ms 118 ms 118 ms > 14 maverick31.sans.org (64.112.229.131) 142 ms 116 ms 118 ms > > Mark Owen wrote: > > Hi All, > > > > Not sure where the problem is at but several packets are being dropped > > to several different hosts from the DC area. (This is not the Google > > DNS problem) > > I tried connecting to several different known sites with roughly 40% > > being unresponsive from two seperate ISPs (Speakeasy and Comcast.) > > > > Traceroute to sans.org via Comcast: > > ~~~~~~~~~~~~~ > > 1 <1 ms <1 ms <1 ms 192.168.20.1 > > 2 12 ms 15 ms 6 ms 10.84.240.1 > > 3 21 ms 11 ms 7 ms ge-2-3-ur02.lanham.md.bad.comcast.net [68.87.131 > > .125] > > 4 8 ms 12 ms 32 ms te-9-1-ur01.lanham.md.bad.comcast.net [68.87.129 > > .61] > > 5 11 ms 21 ms 9 ms te-9-1-ur01.bowie.md.bad.comcast.net [68.87.128. > > 177] > > 6 8 ms 6 ms 27 ms te-8-2-ar01.capitolhghts.md.bad.comcast.net [68. > > 87.128.182] > > 7 7 ms 8 ms 8 ms 68.87.16.165 > > 8 15 ms 9 ms 7 ms 12.118.122.9 > > 9 8 ms 9 ms 9 ms tbr1-p010401.wswdc.ip.att.net [12.123.9.106] > > 10 7 ms 8 ms 8 ms ggr2-p300.wswdc.ip.att.net [12.123.9.81] > > 11 10 ms 9 ms 12 ms att-gw.dc.sprint.net [192.205.32.166] > > 12 27 ms 13 ms 9 ms sl-bb26-rly-5-0.sprintlink.net [144.232.20.149] > > > > 13 39 ms 33 ms 32 ms sl-bb25-chi-3-0.sprintlink.net [144.232.20.89] > > 14 78 ms 76 ms 84 ms sl-bb21-sea-1-0.sprintlink.net [144.232.20.156] > > > > 15 75 ms 77 ms 74 ms sl-bb20-sea-15-0.sprintlink.net [144.232.6.89] > > 16 75 ms 74 ms 81 ms sl-bb22-tac-6-0.sprintlink.net [144.232.9.151] > > 17 77 ms 75 ms 75 ms sl-bb21-tac-4-0.sprintlink.net [144.232.17.93] > > 18 76 ms 76 ms 76 ms sl-gw6-tac-10-0.sprintlink.net [144.232.17.1] > > 19 88 ms 83 ms 86 ms sl-micro23-1-0-0.sprintlink.net [160.81.243.66] > > > > 20 82 ms 80 ms 83 ms 64-112-224-3-ips-eug-or-core02.tcpipservices.net > > [64.112.224.3] > > 21 86 ms 85 ms 84 ms 64-112-227-69-ips-eug-or-lb01-2.tcpipservices.ne > > t [64.112.227.69] > > 22 maverick32.sans.org [64.112.229.132] reports: Destination host > > unreachable. > > > > ~~~~~~~~~~~~~~~~~~~~~~~ > > Traceroute via Speakeasy would timeout. > > > > Same thing goes for other sites > > ubuntulinux.org > > www.osvdb.org for example. > > > > Anyone else having similar problems? > > > -- Mark Owen -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0