- Test - lists.nanog.org

RE: Sitefinder II, the sequel...
by Joseph Jackson 11 Jul '06

11 Jul '06

I agree. I think this isn't a bad service. If people want to run it more power to them. > -----Original Message----- > From: Daniel Golding [mailto:dgolding@tier1research.com] > Sent: Tuesday, July 11, 2006 12:22 PM > To: 'Stephane Bortzmeyer'; 'Steve Sobol' > Cc: Joseph Jackson; nanog(a)nanog.org > Subject: RE: Sitefinder II, the sequel... > > > That's absolutely ridiculous. Enterprise IT organizations > make decisions on behalf of their userbase all day. Frankly, > I'd be shocked if many tried this out - most enterprises run > their own DNS servers as part of an Active Directory scheme. > In any case, those workstations belong to the enterprise and > they can point them to whatever DNS servers they want. > > For most end-users, their Internet access provider already > selects their DNS caching server. ISPs are within their > rights to do this - I'm surprised most broadband ISPs haven't > done exactly what OpenDNS is doing to generate revenue. > > I'm sure if you look really hard, you can find something else > to be outraged about. OpenDNS isn't it. I'm at a loss to > explain why people are trying so hard to condemn something like this. > > - Daniel Golding > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] > On Behalf > > Of Stephane Bortzmeyer > > Sent: Tuesday, July 11, 2006 3:09 AM > > To: Steve Sobol > > Cc: Joseph Jackson; nanog(a)nanog.org > > Subject: Re: Sitefinder II, the sequel... > > > > > > On Mon, Jul 10, 2006 at 11:19:51PM -0700, Steve Sobol > > <sjsobol(a)JustThe.net> wrote a message of 16 lines which said: > > > > > There's a big difference, of course, between > INTENTIONALLY pointing > > > your computers at DNS servers that do this kind of thing, > and having > > > it done for you without your knowledge and/or consent. > > > > As Steven Bellovin pointed out, most OpenDNS users will not > choose it: > > it will be choosen for them by their corporate IT department or by > > their Internet access provider. > > >

1 0

(2nd) Call for Volunteers for Mailing List Administration Panel
by Randy Bush 11 Jul '06

11 Jul '06

There is an opening on the NANOG Mail List Administration Panel. According to the draft charter[1]: "... The NANOG list will be administered and minimally moderated by a panel selected by the Steering Committee." Accordingly, the Steering Committee is soliciting nominations for this open position, from now through 17:00 GMT Thursday, August 13, 2006. ** Procedure ** To volunteer yourself or nominate someone else, please send mail to steering(a)nanog.org with the following information, no later than 17:00 GMT Sunday August 13, 2006. - Your name - Nominee's name (if not you) - Nominee's email address - Nominee's phone number - Nominee's employer - Reasons why you believe the nominee is qualified to serve on the Mail List Panel. We will contact each of the nominees to verify interest and possibly request additional information. Once all nominations have been received, the Steering Committee, in cooperation with the Mailing List Panel, will select the new member from among the nominees. The result will be announced on the nanog-announce mailing list. ** Eligibility ** Anyone actively reading the nanog(a)nanog.org mailing list is eligible. A nominee may not be a member of the NANOG Program Committee or of the NANOG Steering Committee. ** Duties ** Basic duties include reading the mailing list and assisting with keeping things on-topic. The team also deals with abuse issues as they arise. ** Length of term ** The charter does not specify ML Panel member term lengths. Open discussion of this is being led by the NANOG Steering Committee. If you have any questions, please post to the meta-discussion list, nanog-futures(a)nanog.org, or email nanog-admin(a)nanog.org and steering(a)nanog.org. Finally, on behalf of the Mailing List Panel and the Steering Committee, we would like to thank everyone for their help in making NANOG a useful environment for operators. randy for the SC & Chris Malayter, for the MLC

1 0

Re: Net Neutrality Legislative Proposal
by Fergie 11 Jul '06

11 Jul '06

I disagree with your statement on NAT end-points not being "publicly accessible" -- that's certainly not true, and a myth that needs to be finally killed. The "statefulness" of the NAT gateway handles that -- it's a non-issue. I get really tired of hearing people perpetuate this mistruth. Of course, my comment on this has nothing to do with whatever the original thread was... - ferg -- Florian Weimer <fw(a)deneb.enyo.de> wrote: [snip] So I put all my customers behind a NAT device (or just a stateful packet filter). They are no longer publicly accessible, and hence not subject to the provisions of this section. Fixing that would probably require companies to open up their corporate networks, which is a non-starter. (I've wondered for quite some time if "net neutrality" implies that Ebay or Google must carry third party traffic on their corporate networks, by the way.) -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Re: Sitefinder II, the sequel...
by Joseph Jackson 11 Jul '06

11 Jul '06

If its their corp IT peopl. Oh well they should get over it. If isp vote with your dollars. -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Tue Jul 11 00:09:25 2006 To: Steve Sobol Cc: Joseph Jackson; nanog(a)nanog.org Subject: Re: Sitefinder II, the sequel... On Mon, Jul 10, 2006 at 11:19:51PM -0700, Steve Sobol <sjsobol(a)JustThe.net> wrote a message of 16 lines which said: > There's a big difference, of course, between INTENTIONALLY pointing > your computers at DNS servers that do this kind of thing, and having > it done for you without your knowledge and/or consent. As Steven Bellovin pointed out, most OpenDNS users will not choose it: it will be choosen for them by their corporate IT department or by their Internet access provider.

2 1

RE: Best practices inquiry: filtering 128/1
by WONG, Yuen-Fung 11 Jul '06

11 Jul '06

> Would anyone not filter those routes? Why wouldn't you filter to /7? > > Actually, I take that back. Why wouldn't you just get a feed from > Cymru <http://www.cymru.com/Bogons/index.html> ?? > We had some hesitation on putting in a 1/ le /7 filter as these are not mentioned in any document / recommendation that they are invalid / bogus routes... nor in the Cymru. Anyway, just spotted this in Cymru [Ingress Prefix Filter Templates, Loose and Strict (Cisco)] but it was not included / mentioned in their fltr-bogons: ! Block Prefixes less than /5. ! ip prefix-list ISP-Ingress-In-Loose seq 50 deny 0.0.0.0/0 le 5 ! ! Block /6 and /7 prefixes - We have this in as a marker to see if any of the ! large networks pull together any /8s into smaller blocks. Watch this hit ! counters with "show ip prefix". Tuned per Adriana Vascan <avascan(a)cisco.com> ! suggestion. ! ip prefix-list ISP-Ingress-In-Loose seq 55 deny 0.0.0.0/0 le 6 ip prefix-list ISP-Ingress-In-Loose seq 60 deny 0.0.0.0/0 le 7 ! -yf

1 0

APRICOT 2007 Call for Papers
by Jonny Martin 11 Jul '06

11 Jul '06

Hi All. The APRICOT 2007 call for papers is now open, as per the following. Cheers, Jonny Martin APRICOT Program Committee --- Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) Bali, Indonesia 21st Feb - 2nd March 2007 http://www.2007.apricot.net Call for Papers The APRICOT 2007 Program Committee is now seeking contributors to the program. This is the main call for Presentations & Tutorials before the final program is fixed. We would like to give people the opportunity to submit their proposals early and to encourage people in the Asia Pacific region who have not previously presented their work to do so. We are looking for people who would like to: * Offer a technical tutorial on an appropriate topic; and/or * Participate in the technical conference sessions as a speaker; and/or * Convene and chair a Birds of a Feather (BOF) session. CONFERENCE MILESTONES --------------------- Call for Papers Opens: 1 July 2006 Deadline for Speaker Submissions: 30 October 2006 First Draft Program Published: 15 November 2006 Final Program Published: 15 January 2007 PROGRAM MATERIAL ---------------- APRICOT 2007 will be arranged into six operational streams, each of which will contain a number of conference tracks and related tutorials. This streamed approach is designed to foster operational communities within the Asia Pacific region. Each stream will take place in the same area providing opportunity for people do further discuss and network with peers. Streams for APRICOT 2007 are: 1. Routing Operations IPv4 and IPv6 Routing, APNIC Routing and IPv6 Technical SIG, MPLS, Backbone operations. 2. Services Operations DNS, VOIP, ENUM, IDN, IDC, content and other services, APNIC DNS SIG. 3. Security Operations NSP-Sec, DDoS, Security Operations, Anti-SPAM, Anti-Malware. 4. Internet Provider Relationships IXP Operations, Peering, APNIC IX SIG. 5. Access Technologies Wireless, WiMax, Metro Ethernet, DSL, Broadband access aggregation. 6. APNIC Stream APNIC's NIR, Database, Policy SIGs. TUTORIALS Tutorials are full-day workshops which focus on a particular subject in-depth. They may be presented by a single Instructor, or a team of instructors working together. Tutorial Instructors are encouraged to also sign up to be a Speaker in the Technical Conference Program as well. You can sign up to give a tutorial and/or conference session presentation by following the instructions at the end of this message for signing up as a speaker or instructor. Tutorial topics which have successful in the past, or have been requested for this year are: - Network security, IPSec, Auditing/Forensics, DDoS Mitigation, VoIP Security - Address planning, conservation, responsibility and migration to IPv6 - High performance IP backbone routing and management - BGP MultiHoming - MPLS - IPv6 implementation - Network planning, management and traffic engineering - Internet exchanges, construction, peering and collocation - Operations, NOC, Helpdesk and other support aspects - BIND, DNSSEC, Split Horizon DNS, and Reverse and multilingual DNS - Broadband first/last mile access technologies - Mobile and wireless technologies - Content, Applications, streaming and multimedia infrastructure - VoIP, Unified messaging, scaling e-mail infrastructure, Asterisk, etc. - Hosted Essential Services (mail, DNS, etc), Server scaling, Open source - Quantitative Analysis for Internet Public Policy The program committee will consider proposals for tutorials in any of these areas, and also in new areas. There will be two days of Tutorials. Tutorials last 1/2 day or a full day and can cater to beginner through to advanced audiences. Tutorial days are typically split into four 1.5 hour sessions. If you have an idea for a tutorial subject that is not listed, please feel free to submit it to us. TECHNICAL CONFERENCE SESSIONS The Main Conference Program for 2006 will be made up of two days, with three streams each day. In addition there will be a stream focused on local (Indonesian) internet issues. Each stream will consist of four 1.5 hour sessions, with each having three or four presentations. This allows 20-30mins per presenter. Sessions are chaired by persons of appropriate expertise in the subject matter of the session and will include ample time for questions from the audience. Successful presentations from past APRICOTs have covered topics relevant to current operational deployments or new technologies not yet in wide deployment. Proposals for conference presentations are invited for topics fitting into the six streams outlined above. If you would like to give a presentation at one or more of the sessions, follow the instructions at the end of this message for signing up as a speaker or instructor. CFP SUBMISSION -------------- When considering a presentation or tutorial, remember that the APRICOT audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills and basic knowledge in the tutorials and to address issues relevant to the day-to-day operations of ISPs and network operators over the next 12 - 18 months in the conference sessions. The deadline for submissions is 30 October, 2006. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. Final slides are to be provided by 15 January, 2007. While the majority of speaking slots will be submitted by 30 October 2006, a limited number of slots may be available for presentations that are exceptionally timely, important, or of critical operational importance. IMPORTANT NOTE -------------- APRICOT is a TECHNICAL conference so marketing and commercial content is not allowed within the program. The program committee is charged with maintaining the technical standard of APRICOT, and will therefore not accept inappropriate materials. It is expected that the presenter be a technical person and not a sales or marketing person. The audience is extremely technical and expects that the speakers are themselves very knowledgeable. All sessions provide time for questions, so presenters should expect technical questions and be prepared to deliver insightful and technically deep responses. FUNDING AND SUPPORT ------------------- APRICOT is a not-for-profit event that tries to keep the cost to attendees low so we are unable to pay the travel costs of speakers. Speakers from developing countries may be eligible for the APRICOT Fellowship Program which provides basic assistance to successful fellows to cover local living and registration expenses associated with attending the conference. Of course, Tutorial instructors will not have to pay any registration fee to attend the conference or tutorials, and Conference Speakers do not have to pay for registration to the Technical Conference. SIGNING UP AS A SPEAKER, INSTRUCTOR OR BOF Convener If you would like to be considered as a tutorial instructor, session speaker, or a convener of a BOF, please fillin the form at http:// submission.apricot.net/ More information on the conference is available at http:/www.2007.apricot.net Thanks, APRICOT Program Committee program(a)apricot.net

1 0

Re: Best practices inquiry: filtering 128/1
by Patrick W. Gilmore 11 Jul '06

11 Jul '06

On Jul 10, 2006, at 10:18 PM, Valdis.Kletnieks(a)vt.edu wrote: > On Mon, 10 Jul 2006 22:00:11 EDT, "Patrick W. Gilmore" said: >> >> On Jul 10, 2006, at 9:48 PM, WONG, Yuen-Fung wrote: >> >>> Sometimes earlier this year someone announced this 128/1 and caused >>> heavy loading to our routers to rebuild the CEF. >>> Would anyone filter out this route (and other similar routes such >>> as 0/1, 128/1, 0/2, 64/2, .... up to /4, for example) as bogus >>> routes? >> >> Would anyone not filter those routes? Why wouldn't you filter to /7? > > Every growing season, a new crop of network engineers falls fresh from > the tree, and must be picked up, polished, and clue imparted on the > way to market..... Well, then don't snip the most important clue in the post: > Actually, I take that back. Why wouldn't you just get a feed from > Cymru <http://www.cymru.com/Bogons/index.html> ?? :-) -- TTFN, patrick

1 0

Fridays are always good for shock headlines...
by Fergie 10 Jul '06

10 Jul '06

Nothing new here, but just an FYI -- I figured some of you might want to be aware new pressures being exerted in the CALEA arena. Via C|Net. [snip] The FBI has drafted sweeping legislation that would require Internet service providers to create wiretapping hubs for police surveillance and force makers of networking gear to build in backdoors for eavesdropping, CNET News.com has learned. [snip] More: http://news.com.com/2100-1028_3-6091942.html - ferg p.s. When did the FBI start drafting legislation? ;-) -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

4 4

Best practices inquiry: tracking SSH host keys
by Phillip Vandry 10 Jul '06

10 Jul '06

We all know that the weakest link of SSH is key management: if you do not confirm by a secure out of band channel that the public host key of the device you are connecting to is correct, then SSH's crypto will not help you. SSH implements neither a CA hierarchy (like X.509 certificates) nor a web of trust (like PGP) so you are left checking the validity of host keys yourself. Still, it's not so bad if you only connect to a small handful of well known servers. You will either have verified them all soon enough and not be bothered with it anymore, or system administrators will maintain a global known_hosts file that lists all the correct ones. But it's quite different when you manage a network of hundreds or thousands of devices. I find myself connecting to devices I've never connected to before on a regular basis and being prompted to verify the public host keys they are offering up. This happens in the course of something else that I am doing and I don't necesarily have the time to check a host key. If I did have time, it's hard to check it anyway: the device is just one of a huge number of network elements of no special significance to me and I didn't install it and generate its key and I don't know who did. >From time to time I also get hit with warning messages from my SSH client about a changed host key and it's probably just that someone swapped out the router's hardware sometime since the last time I connected and a new key got generated. But I'm not sure. Worst of all, my problem is repeated for every user because each user is working with their own private ssh_known_hosts database into which they accept host keys. A possible solution is: - Maintain a global known_hosts file. Make everyone who installs a new router or turns up SSH on an existing one contribute to it. Install it as the global (in /etc/) known_hosts file on all the ssh clients you can. Pro: The work to accept a new host key is done one, and it's done by the person who installed the router, who is in the best position to confirm that no man in the middle attack is taking place. Con: You need to make sure updates to this file are authentic (its benefit is lost if untrusted people are allowed to contribute), and you need to be sure it gets installed on the ssh clients people use to connect to the network elements. Con: If a host key changes but it is found to be benign (such as the scenario I describe above), users can't do much about it until the global file is corrected and redeployed (complicated openssh options which users will generally not know to bypass the problem notwithstanding). I'm looking for information on best practices that are in use to tackle this problem. What solutions are working for you? Thanks -Phil

10 15

Re: NANOG Spam?
by William Allen Simpson 10 Jul '06

10 Jul '06

Christian Seitz <chris(a)in-berlin.de> wrote: > In article <44AC3493.6010705(a)gmail.com> you wrote: > >> oarwind.info. >> AS | IP | Registry | AS Name >> 6724 | 81.169.143.178 | ripencc | STRATO Strato AG > > How did you resolve this? Is there something wrong with > my DNS or did you make a mistake resolving the adress? > > oarwind.info A 218.22.43.22 > > inetnum: 218.22.0.0 - 218.23.255.255 > netname: CHINANET-AH > country: CN > descr: CHINANET Anhui province network > descr: Data Communication Division > descr: China Telecom > admin-c: CH93-AP > tech-c: AT318-AP > status: ALLOCATED PORTABLE > mnt-by: APNIC-HM > mnt-lower: MAINT-CHINANET-AH > changed: hm-changed(a)apnic.net 20060322 > source: APNIC > At the time of resolution 3 days ago, multiple persons on this list resolved it to Strato.de. h613092.serverkompetenz.net (81.169.143.178) Apparently, it has since moved to China. That's the kind of thing that happens while you took a long weekend. Are you in a position to quarantine the German server? Or otherwise aid in investigating the problem? Such as getting German law enforcement to confiscate the server as compromised and containing personal identity theft?

1 1