- NANOG - lists.nanog.org

Re: Re: Re: KPNQwest ns.eu.net server.
by Arnold Nipper 07 Jun '02

07 Jun '02

Hallo Sabine, lange nichts gehoert ... On Fri, Jun 07, 2002 at 09:51:11AM +0200, Sabine Dolderer/Denic wrote: > > > > At least each IXP member would have direct connectivity to such > > infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their > > customers would benefit from it. > > I agree that IXPs would be very gould locations as they offer network > diversity, but there is one question still open and that is who will be the > one running the and monitoring the server. And we at DENIC have seen in the > last years an increasing demand in running the servics by ourself as only > then we have the complete control and information about statistics, network > attacks, performance ... > Keep it simple ... the IXPs (e.g. Euro-IX) could/should provide the basis. I.e. taking care for excellent colo, sufficient connectivity, one-stop-shop etc. Interested parties would install the services by themselves and would be responsible to run them. Parties could be CENTR, DE-NIC, ICANN, EUxxx and so on. I would like to know more about the CENTR sss iniative. Whom should I contact? Arnold -- Arnold Nipper Email: arnold.nipper(a)de-cix.net DE-CIX, The German Internet Exchange Mobile: +49 172 2650958

1 0

Re: Re: KPNQwest ns.eu.net server.
by Nipper, Arnold 07 Jun '02

07 Jun '02

As a lot of people are offering secondary services: may be it's a good idea to place infrastructural services at IXP. IXP seem to be more stable than any ISPs and often more neutral than ISPs. Comments? Arnold -- Arnold Nipper, DE-CIX, the German Internet Exchange email: arnold.nipper(a)de-cix.net mobile: +49 172 2650958 handle: an6695-ripe ----- Original Message ----- From: "Sabine Dolderer/Denic" <dolderer(a)denic.de> To: "Jan-Ahrent Czmok" <czmok(a)gatel.net> Cc: <apnic-talk(a)lists.apnic.net>; <apops(a)lists.apnic.net>; <ddiaz(a)ripe.net>; <joao(a)ripe.net>; <lir-wg(a)ripe.net>; <nanog(a)merit.edu>; <randy(a)psg.com>; <routing-wg(a)ripe.net>; <tech-l(a)ams-ix.net> Sent: Thursday, June 06, 2002 9:43 AM Subject: Re: Re: KPNQwest ns.eu.net server. Hello, DENIC runs currently several secondarys (not only DE but also for some other TLDs) in different places worldwide. We are willing to offer secondary service for other ccTLDs. But there will be because of security/stability reasons a limit on the number of ccTLDs we want to run on a single machine. Sabine -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 Jan-Ahrent Czmok An: Joao Luis Silva Damas <joao(a)ripe.net> <czmok@gatel. Kopie: randy(a)psg.com, ddiaz(a)ripe.net, routing-wg(a)ripe.net, net> lir-wg(a)ripe.net, tech-l(a)ams-ix.net, apops(a)lists.apnic.net, Gesendet von: nanog(a)merit.edu, apnic-talk(a)lists.apnic.net owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net server. ripe.net 06.06.2002 01:29 PostedDate: 06.06.2002 01:29:37 $MessageID: <20020606012937.2c476312.czmok(a)gatel.net> From: owner-lir-wg(a)ripe.net SendTo: Joao Luis Silva Damas <joao(a)ripe.net> CopyTo: randy@psg.com;ddiaz@ripe.net;routing-wg@ripe.net;lir-wg@ripe.net;tech-l@ams- ix.net;apops@lists.apnic.net;nanog@merit.edu;apnic-talk@lists.apnic.net Subject: Re: KPNQwest ns.eu.net server. Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 ; Thu, 6 Jun 2002 01:28:35 +0200 Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 +0200 Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 Delivered_To: lists-lir-wg-out(a)lists.ripe.net PRINCIPAL: Jan-Ahrent Czmok <czmok(a)gatel.net> In_Reply_To: <p05111700b92449b9ddee(a)[193.0.1.81]> References: <200206051725.g55HPlA05396(a)birch.ripe.net> <E17Ff8f-0003So-00(a)roam.psg.com> <p05111700b92449b9ddee(a)[193.0.1.81]> Organization: Global Access Telecommunications Inc. $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) X_Ncc_RegID: de.gatel MIME_Version: 1.0 Precedence: bulk X_Loop_Detect: RIPE NCC SMTPOriginator: owner-lir-wg(a)ripe.net RouteServers: CN=notes/O=Denic RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 DeliveredDate: 06.06.2002 01:28:38 DENICDOCOPENCOUNT: 1 $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 BlindCopyTo: WebSubject: Re: KPNQwest ns.eu.net server. On Thu, 6 Jun 2002 01:08:46 +0200 Joao Luis Silva Damas <joao(a)ripe.net> wrote: > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > Given the current situation of KPNQwest and the possibility > >> of its services going offline sometime soon, the RIPE NCC in > >> agreement with KPNQwest will be temporally hosting this > >> server (ns.eu.net) in its premises. > > > >nice emergency hack and sorry to whine. but i used them both > >to get diversity. > > Hi Randy, > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > secondary. So we will definitely request those ccTLDs to look for a > new host as soon as possible. Hi Randy, hi Joao, dear routing-wg, probably my Company (GATEL, AS13129) is able to host a secondary server for the ccTLDs. The question is rather what are the hardware "requirements" for the secondary server. We have sufficient bandwidth capacity available and rack space as well. > The rest can take bit more time to think what they want to do since > ns.eu.net will keep running. Well done ! Congrats for the good ideas and coordination work. > > We are offering secondary service on ns.ripe.net for any ccTLD that > we weren't sencodaring for, as are other people. > > The idea is not to have ns.eu.net running for ever, just to enable > people to have time to take rational decisions, without the fear of > having the server going away because of some unexpected turn of > events. > > > > >when in less of a panic, please move it to moscow or something. > > Panic? what panic? this is just common sense > right. it's not panic. --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok(a)gatel.de

9 8

Fw: [swinog] Contact @ AOL?
by Pascal Gloor 07 Jun '02

07 Jun '02

Please reply to him directly, thanks, Pascal ----- Original Message ----- From: "Benoit Panizzon" <panizzon(a)woody.ch> To: <swinog(a)swinog.ch> Sent: Thursday, June 06, 2002 9:32 PM Subject: [swinog] Contact @ AOL? > Does somebody have any contact to an AOL hostmaster or abuse person? > > Since about three months I get multiple attempts to send spam via a > Formmail installation every day from the AOL.COM IP-Range. I forward the > logs to abuse(a)aol.com nearly every day but I never get any human answering > my emails. I also called AOL in Germany but they don't know who I should > contact or how I should escalate that problem. (They just told me > abuse(a)aol.com are the only ones known to care about such problems). > > PS: It's a secured Formmail and those attempts were all unsuccessfull, so > no need to tell me it's not secure ;-) > > Benoit Panizzon > > ASCII-Ribbon Campaign > """"""""""""""""""""" > No HTML or WORD in Mails > HTML is for WEB, Word is for Micro$oft. > ** Get stoned - drink wet concrete > > ---------------------------------------------- > swinog(a)swinog.ch Maillist-Archive: > http://www.mail-archive.com/swinog%40swinog.ch/ >

1 0

it's official
by smd＠clock.org 06 Jun '02

06 Jun '02

i hate spamarrest. i really do. i hate it. as if i don't get enough junk mail from the nanog list itself, and the advertisers who troll it. you don't know who you are, but lots of the rest of us do. Sean.

3 2

Diagnostic Tools
by Pawlukiewicz Jane 06 Jun '02

06 Jun '02

Hi, I'm new here but I already have a quick question. What are the best diagnostic tools available to network operators today? Thanks for any info, Jane

4 5

Results of query on auth usage
by Barbara Fraser 06 Jun '02

06 Jun '02

I received 20 responses which isn't exactly overwhelming :-). All of the responses included usage information for eBGP-MD5 and a few provided information on MD5 for interior protocols. In addition to these 20 I also received a few more with commentary. Conclusion from these messages? + only 2 required their peers to use eBGP-MD5 + many wanted to use it but peers either refused or didn't know how + some issues concerning whether this protects you from any "real" threat So, there you have it. Below are the breakouts and miscellaneous remarks that were included in the email I received. Thanks to all of you who took the time to send me something. Barb ================================== eBGP-MD5 use 2 responded that they used it and required it of all peers 12 others replied they used BGP-MD5 whenever their peers supported it 1 replied they use it only when required by a peer 5 said they do not use it Specific usage comments: Out of 100+ peers, only 1 requires it I use MD5 with BGP where I can, but <ISP> told me they don't support it so I'm limited in where I can deploy. 1 out of 25+ peers supports it 1 or 2 out of the 80+ eBGP sessions support it 2 out of 200 eBGP sessions support it iBGP/OSPF/ISIS with MD5 2 reported using this but were in the 5 above that don't use eBGP-MD5 4 others reported using this as well as eBGP-MD5 no reports of using ISIS w MD5 1 said they do not use it Miscellaneous comments: + For the most part, the greater vulnerability (still not well-understood by the script-kiddie community, thankfully) is probably a simple DoS of the appropriate listening port for the routing protocol. + It is our belief that it is highly unlikely that someone would have into your network to inject erroneous route advertisements. + The most difficult challenge I face there is convincing people of the "need" with the lack of a published exploit that the MD5 authentication would prevent. + Despite all the whining about the potential for an attack, I'm not aware of anyone having actually done so. Routers are notoriously under-CPU'd, and I think most engineers would rather have routes converge 30% faster than protect against an attack noone has ever done. + no hacker could figure out how to get into the infrastructure far enough to attack that so it's not worth attacking +.It is very hard for a big provider to change their procedure for setting up MD5 authentication + Some ISPs are practically religious about using them, usually the result of a single person at the ISP pushing it. + On a case by case basis you can get most ISPs to setup MD5 on your particular BGP session, once you found the right engineer. + The person at the other end didn't know how to enable it so you couldn't do it + As far as internal IGP (OSPF) MD5 authentication, I was always a little leary of using it because I wasn't comfortable with key rollover when you approached the maximum number of key-id's, (I believe it was 255). At that point, you're forced to take a hit when you have to remove the key entirely and start from a low integer value key-id. Had that limitation not been there, I would've deployed IGP MD5 authentication.

2 2

Re: Diagnostic Tools
by Pawlukiewicz Jane 06 Jun '02

06 Jun '02

No. But I was thinking of something more robust. And I think it depends on what level you want your diagnostics to go to. Then there's metrics, analysis, detection processes. Ping and traceroute give me a ton of data. I was thinking of something that takes that data and turns it into the bottom line. Where is the problem, when did it start, all the good stuff. I still can't believe someone hasn't cashed in on this. Or is it something you wouldn't need or use? Jane Marc Pierrat wrote: > > Is there a problem with good ol' fashioned ping and traceroute? They're on every platform, even windows. > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > Pawlukiewicz Jane > > Sent: Thursday, June 06, 2002 12:39 PM > > To: Nicolas Maton; nanog(a)merit.edu > > Subject: Re: Diagnostic Tools > > > > > > Sorry it took so long to reply. Work gets in the way... > > > > Nicolas Maton wrote: > > > > > > hmmm, > > > > > > I still don't get the global picture?? > > > You want to poll routers andso outside of your network ? > > > > That's the idea I had, yeah. The traffic on my network is not hard to > > pull. We can analyze that data forever. What I'm curious about is the > > performance, or detection of problems in the routers that serve other > > networks, the gateways. Not like I'm curious about your internal network > > or anything, just there should be some way to determine the what, where, > > when of a boggle on the internet. > > > > I thought by now there'd be a nice package we could buy from somebody > > that would pinpoint the problem(s). I was told they haven't developed > > that yet and couldn't believe it. > > > > > > > > If you have access to them you can use some monitoring software like > > > > > > Big Brother > > > HP openvieuw > > > Aprisma Spectrum > > > CiscoWorks > > > and so on..... > > > > > > If you mean something else please let me know so i can search > > an solution with you. > > > > I'm not sure yet. Access is the rub, I think. Everyone is so proprietary > > these days. I suppose it doesn't matter. > > > > > > > > <<< Cogito ergo sum >>> > > > > ?? (as in, what does that mean?) > > > > > > Nicolas Maton > > > Network Engineer > > > s.a. Tiscali Belgium n.v. > > > Rue de Stassart 43 de Stassartstraat > > > 1050 Brussel -Bruxelles > > > Belgie-Belgique > > > NEW Direct number:+32 (0)2 4003663 > > > NEW Cell Phone:+32 (0)498 889363 > > > E-mail: nmaton(a)be.tiscali.com > > > http://www.tiscali.be > > > > > > This email and any attachments may be confidential and the > > subject of legal > > > professional privilege. Any disclosure, use, storage or copying of this > > > email without the consent of the sender is strictly prohibited. Please > > > notify the sender immediately if you are not the intended > > recipient and then > > > delete the email from your inbox and do not disclose the > > contents to another > > > person, use, copy or store the information in any medium. > > > ********************************************************************** > > > > > > -----Original Message----- > > > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > > > Sent: donderdag 6 juni 2002 16:01 > > > To: Nicolas Maton > > > Subject: Re: Diagnostic Tools > > > > > > Thanks for responding so quickly. > > > > > > I think I need to rephrase the question. I'm not thinking of diagnostics > > > on a specific network, as in my company's intranetwork. I'm thinking > > > there must be a set of diagnostic tools to determine where the problem > > > is outside of my network. If its platform specific it wouldn't work very > > > well, would it? > > > > > > I was just thinking again. A dangerous hobby. > > > > > > Thanks, > > > > > > Jane > > > > > > Nicolas Maton wrote: > > > > > > > > For what platform? > > > > > > > > -----Original Message----- > > > > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > > > > Sent: donderdag 6 juni 2002 15:51 > > > > To: nanog(a)merit.edu > > > > Subject: Diagnostic Tools > > > > > > > > Hi, > > > > > > > > I'm new here but I already have a quick question. > > > > > > > > What are the best diagnostic tools available to network > > operators today? > > > > > > > > Thanks for any info, > > > > > > > > Jane

4 3

Re: Diagnostic Tools
by Pawlukiewicz Jane 06 Jun '02

06 Jun '02

Sorry it took so long to reply. Work gets in the way... Nicolas Maton wrote: > > hmmm, > > I still don't get the global picture?? > You want to poll routers andso outside of your network ? That's the idea I had, yeah. The traffic on my network is not hard to pull. We can analyze that data forever. What I'm curious about is the performance, or detection of problems in the routers that serve other networks, the gateways. Not like I'm curious about your internal network or anything, just there should be some way to determine the what, where, when of a boggle on the internet. I thought by now there'd be a nice package we could buy from somebody that would pinpoint the problem(s). I was told they haven't developed that yet and couldn't believe it. > > If you have access to them you can use some monitoring software like > > Big Brother > HP openvieuw > Aprisma Spectrum > CiscoWorks > and so on..... > > If you mean something else please let me know so i can search an solution with you. I'm not sure yet. Access is the rub, I think. Everyone is so proprietary these days. I suppose it doesn't matter. > > <<< Cogito ergo sum >>> ?? (as in, what does that mean?) > > Nicolas Maton > Network Engineer > s.a. Tiscali Belgium n.v. > Rue de Stassart 43 de Stassartstraat > 1050 Brussel -Bruxelles > Belgie-Belgique > NEW Direct number:+32 (0)2 4003663 > NEW Cell Phone:+32 (0)498 889363 > E-mail: nmaton(a)be.tiscali.com > http://www.tiscali.be > > This email and any attachments may be confidential and the subject of legal > professional privilege. Any disclosure, use, storage or copying of this > email without the consent of the sender is strictly prohibited. Please > notify the sender immediately if you are not the intended recipient and then > delete the email from your inbox and do not disclose the contents to another > person, use, copy or store the information in any medium. > ********************************************************************** > > -----Original Message----- > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > Sent: donderdag 6 juni 2002 16:01 > To: Nicolas Maton > Subject: Re: Diagnostic Tools > > Thanks for responding so quickly. > > I think I need to rephrase the question. I'm not thinking of diagnostics > on a specific network, as in my company's intranetwork. I'm thinking > there must be a set of diagnostic tools to determine where the problem > is outside of my network. If its platform specific it wouldn't work very > well, would it? > > I was just thinking again. A dangerous hobby. > > Thanks, > > Jane > > Nicolas Maton wrote: > > > > For what platform? > > > > -----Original Message----- > > From: Pawlukiewicz Jane [mailto:pawlukiewicz_jane@bah.com] > > Sent: donderdag 6 juni 2002 15:51 > > To: nanog(a)merit.edu > > Subject: Diagnostic Tools > > > > Hi, > > > > I'm new here but I already have a quick question. > > > > What are the best diagnostic tools available to network operators today? > > > > Thanks for any info, > > > > Jane

1 0

Re: Bogon list
by smd＠clock.org 06 Jun '02

06 Jun '02

| Why treat exchange subnets differently to any other bit of backbone | infrastructure? Oh, I wholeheartedly agree. I would love them all to use RFC 1918 addresses, because it is VERY VERY VERY rare that anything outside the scope in which the 1918 local use addresses are unique actually has to communicate with backbone infrastructure of any type. What communication can your workstation have with an XYZNET router? Can you log into it? Can you talk SMTP to it? How about SNMP? Oh, I know - you can start up a BGP session with it from your desk, right? In short, ping & traceroute are about the only interaction anyone will ever have with a router that is not under their control, excepting error messages (which is the usual way at least traceroute works), and it is NOT WORTH THE ADDRESS CONSUMPTION just to facilitate this. Regrettably, IP sux in the confusing of "where" and "what", so the only way to know who sent you the error ICMP datagram except by the source address. ICMP types that let one encode a handy URL or maybe some text explaining the error and its source would be cool, and if this is regularized, then there's no point in having global address space consumed by things which are only ever going to have interactive sessions with local hosts, and you get to keep your end-to-end diagnostic regime of incredibly useful, reliable and intuitive tools like traceroute and ping. In the absence of new ICMP messages (which really have to be rolled out "everywhere"), redirecting the attention spent on inducing and interpreting them to an in-the-network tool for diagnosing the condition of a LOCAL set of infrastructure is something I think is quite practical. Perhaps a tiny chunk of address space with useful IN-ADDR.ARPA messages would be a good start. : unix ; traceroute abc.defxyz.net symbolic-name (217.31.0.1) 1 ms 1 ms 1 ms symbolic-name.your.provider.net (217.31.10.2) 5 ms 5 ms 5 ms please-see.http.www.smartprovider.net (223.255.255.1) 50 ms 50 ms 50 ms please-see.http.www.smartprovider.net (223.255.255.1) 60 ms 60 ms 60 ms please-see.http.www.smartprovider.net (223.255.255.1) 65 ms 65 ms 65 ms please-see.http.www.smartprovider.net (223.255.255.1) 70 ms 70 ms 70 ms please-see.http.www.smartprovider.net (223.255.255.1) 75 ms 75 ms 75 ms please-see.http.www.otherprovider.net (223.255.255.2) 79 ms 80 ms 79 ms please-see.http.www.otherprovider.net (223.255.255.2) 85 ms 82 ms 98 ms ... (I was kinda thinking it might be fun for someone with some spare address space to offer up a mapping of A.B.HI.LO with HI.LO being the higher and lower order bytes of an AS number, although obviously that's not necessary, and is going to be wasteful, since people like Joe will think this is so abominable, that they won't have their ASes do it :-) ) | Why number point-to-point links with even locally-unique addresses? iBGP hack requires intra-domain connectivity to work, and may sometimes require distinguished interface addresses; eBGP insists on connectivity between peers in same logical subnet except when you break that with intentional use of knobs. SNMP hack requires interactive intra-domain connectivity to work. SSH (and telnet disaster) requires interactive intra-domain connectivity to work. Ping/traceroute/etc originating from route-server host(s) require interactive intra-domain connectivity to work. All these and more may benefit from discretely numbered interfaces. These numbers may be 1918 addresses, or they be kept discreet. You might think this is rather backwards and Victorian, like hiding the legs of tables from prying eyes through the use of extremely long tablecloths. However, there are people who have had funny carpentry done, who might see this as a feature. | Slashdot readers wielding traceroute can make an annoying pain in the | side of your head, but traceroute and ping are not without their uses. No functionality is broken - it's just you get ICMP messages from things you probably cannot connect to in any meaningful way. Big deal, that's what you have now, pace ping. | Ask people who are cursed with running poorly-documented X.25 networks | (surely there must be some left) how nice it would be to be able to map | the network in-band. Ask them why they don't have any hair left, while | you're at it. MPLS cannot cause baldness. That lot all have thick and fuzzy hair, I think. I'll stick with conventional theory and suggest it might be genes or razors. (Are you gonna call NATs&6to4/faith X.75 gateways? Cool!) | You don't need to deal with the messy traceroute problem if your | consistent and clean architecture doesn't happen to make traceroute | mess :) Right, stop replying to things which are obviously or even probably traceroutes. No more traceroute mess. No more idiotic firewall operators complaining about these damn unreachable and exceeded messages. I think I'm in favour, although I have to admit traceroute can be fun. Did you ever see Louis Mamakos's toy? Sean.

9 11

Re: KPNQwest ns.eu.net server.
by Joao Luis Silva Damas 06 Jun '02

06 Jun '02

At 16:35 +0200 6/6/02, Gert Doering wrote: > >Hmmm? As far as I can see, RIPE has enough providers. The problem is >that the ccTLD secondary server hosted at KQ broke - ns.eu.net has not "broke". At least not yet. KPNQwest still has very competent people (and I would like to specifically thank Berislav Todorovic for embracing the idea of placing ns.eu.net outside KPNQwest to ensure stability and for all the support in actually doing it) The RIPE NCC doesn't currently need further support to operate the service, which is why we volunteered to do it, to provide a stable service until further steps are undertaken without the concern for the time period KPNQwest will be able to continue to operate. With time, since EUNet will not exist, ns.eu.net should also disappear (I am not quite sure the RIPE NCC would want to "own" the eu.net domain), but it should be after everyone has got time to think properly about a solution that suits them in the long term. Cheers, Joao

1 0