- Test - lists.nanog.org

pre-nanog dns-operations workshop
by brett watson 25 May '06

25 May '06

If anyone is interested in attending a 1-day pre-nanog (June 2) workshop for dns-operations, details can be found at the URL below. http://public.oarci.net/dns-operations/workshop-2006 -b

1 0

Re: Black Frog - the botnets keep coming
by Scott Weeks 25 May '06

25 May '06

----- Original Message Follows ----- From: Henry Linneweh <hrlinneweh(a)sbcglobal.net> > Personally as a manager I want to know the problem and > then the workable solution. I just don't see that many > bot nets happening anymore. You aren't looking close enough. Go to any university network, run NTop at the top of the network or Nessus scans and you'll find the drones communicating in surprising numbers. All you have to do is proactively look for them and you'll find them... scott

1 0

bgp question
by adrian kok 25 May '06

25 May '06

Hi all Thank you all for your answer to my previous question 'RFC1918 from ISP' I have another BGP question, and may be related to BGP dampening. We have a client whose IP is in the block X.X.0.0/19 which doesn't show in our router. However, our BGP log records that we have received this route from our peer isp. I reboot the router, seeing that the route was in our router only to disappear again after couple of minutes. I suspect that it may have been removed by the BGP dampening feature in our router. By disabling the feature, the route will stay in our router. Q1/ My only understanding of the benefit of this feature is to prevent 'unstable' route from flooding to our router, causing a CPU overflow. What's the risk of leaving this off? Q2/ What is the cause of these route that frequently send to our router as stated below? Once our other routes are in our BGP DB, then it will not be re-broadcast to us except withdraw from our peer isp > 2006/05/26 08:30:34 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:33:42 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:36:46 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:39:49 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:45:25 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:48:00 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:49:02 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:51:34 BGP: our-peer-isp rcvd x.x.0.0/19 > 2006/05/26 08:52:36 BGP: our-peer-isp rcvd x.x.0.0/19 Q3/ Do you know any good website to montior the routing network? I just heard this scoreboard.keynote.com from http://isc.sans.org/diary.php but it needs register Thank you very much

2 1

Re: private ip addresses from ISP
by Robert Bonomi 25 May '06

25 May '06

> Date: Tue, 23 May 2006 09:36:30 -0400 > To: nanog(a)nanog.org > From: Daniel Senie <dts(a)senie.com> > Subject: Re: private ip addresses from ISP > > > At 09:22 AM 5/23/2006, Robert Bonomi wrote: > > > > Date: Tue, 23 May 2006 03:33:34 -0400 > > > From: Richard A Steenbergen <ras(a)e-gerbil.net> > > > To: nanog(a)nanog.org > > > Subject: Re: private ip addresses from ISP > > > > > > > > > On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote: > > > > > > > > > 3) You are seeing packets with source IPs inside private space > > > > > arriving at > > > > > your interface from your ISP? > > > ... > > > > Sorry to dig this up from last week but I have to strongly disagree with > > > > point #3. > > > > >From RFC 1918 > > > > Because private addresses have no global meaning, routing information > > > > about private networks shall not be propagated on inter-enterprise > > > > links, and packets with private source or destination addresses > > > > should not be forwarded across such links. Routers in networks not > > > > using private address space, especially those of Internet service > > > > providers, are expected to be configured to reject (filter out) > > > > routing information about private networks. > > > > > > > > The ISP shouldn't be "leaving" anything to the end-user, these packets > > > > should be dropped as a matter of course, along with any routing > > > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space > > > > into my network piss me off, and get irate phone calls for their > > > > trouble. > > > > > > The section you quoted from RFC1918 specifically addresses routes, not > > > packets. > > > >I quote, from the material cited above: > > " ..., and packets with private source or destination addresses > > should not be forwarded across such links. ... " > > > >There are some types of packets that can legitimately have RFC1918 source > >addresses -- 'TTL exceeded' for example -- that one should legitimately > >allow across network boundaries. > > Really? You really want TTL-E messages with RFC1918 source addr? Even > if they're used as part of a denial of service attack? Even though > you can't tell where they actually came from? "Can be" is not sufficient (in and of itself, that is) reason to block. _Anything_ "can be" used as part of a DOS attack. TTL-E messages _do_ have legitimate function in network management. TTL-E messages _can_ originate from RFC1918 space, addressed to 'public internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'? Ever use it where packets went across a network using RFC1918 internally? Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses network? If you don't like that example, substitute "host/network unreachable", or 'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet. If you don't get those messages back, you can't communicate. > > > If you're receiving RFC1918 *routes* from anyone, you need to > > > thwack them over the head with a cluebat a couple of times until the cluey > > > filling oozes out. If you're receiving RFC1918 sourced packets, for the > > > most part you really shouldn't care. > > > >*I* care. > > > >When those packets contain 'malicious' content, for example. > > > >When the provider =cannot= tell me which of _their_own_customers_ originated > >that attack, for example. (This provider has inbound source-filtering on > >their Internet 'gateway' routers, but *not* on their customer-facing > >equipment > >(either inbound or outbound.) > > So you really don't want ANY packets with RFC 1918 source addresses > then, not even ICMP TTL-E messages, since they could be used in a > malicious fashion, and you would not be able to determine the true origin. You need to learn to read. I said "malicious content", not 'used in a malicious fashion'. Packets that could have legitimate meaning should be passed on. Packets that _cannot_ have legitimate meaning should not be. > >It's even more comical when the NSP uses RFC1918 space internally, and does > >*not* filter those source addresses from their customers. > > You mean like Comcast using Cisco routers in their head-ends and > having the 10/8 address show up in traceroutes and so forth? not at all. You're either ignorant of network architecture, or trying to pick fights. I was talking about a situation where a customer machine of a network that uses RFC1918 addresses internally starts sending malicious packets with a RFC1918 source address that _matches_ that of one of the *in*use* addresses on the service-provider network. AND the service-provider does not do ingress (from the customer) or egress (to the customer) filtering of RFC1918 address-space. Customer A's machine starts attacking Customer B, C, D, E, F ...; those ill-informed customers don't null-route outbound RFC1918 addresses; you get an 'inadvertent' smurf attack on the NSP resource. It's comical, because the ISP's 'bad practice' facilitated the attack on the ISP. "Traceroute", by the way, *is* one of those 'legitimate' cases for which RFC1918 source-address packets should be allowed across network boundaries. Proper "good net neighbor" egress filtering of RFC1918 source addresses takes a number of separate rules. Several 'allows', followed by a default 'deny'. > Not sure > to what degree it's the NSP's fault vs. the router vendors', but yes. Can't imagine why you think it might be the fault of the router vendor. Can't imagine why think it is somebody's "fault". > > > There are semi-legitimate reasons for > > > packets with those sources addresses to float around the Internet, and > > > they don't hurt anything. > > > >I guess you don't mind paying for transit of packets that _cannot_possibly_ > >have any legitimate purpose on your network. > > Along with this goes the usual flamewar over RFC 2827, ingress > filtering (of which URPF is a subset implementation). If everybody did _egress_ filtering of 'cannot possibly be legitimate' traffic, ingress filtering of that traffic would not be necessary. Unfortunately, not everybody does, so ingress filtering _is_ necessary. 'ingress' filtering is self-defense. 'egress' filtering is about 'being a good net neighbor'. > >Some of us, on the other hand, _do_ object. > > And some of us pay for bandwidth, care about getting congestion > problems from useless traffic, etc. Perhaps it makes the case a lot > clearer for selling "better than equal" service to the highest bidder > if your network is overrun with undesired traffic. > >

9 13

ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]
by Gadi Evron 24 May '06

24 May '06

> Wired posted what are suppossedly the docs Mark Klein wrote 'bout the > NSA sniffing project. Interesting read... > > http://blog.wired.com/27BStroke6/att_klein_wired.pdf > > John Indeed. To be honest, I am more interested in NANOG-related operational issues involved, which I am not sure many here will be able to discuss in case they had experience on the subject. So let us put privacy and legal issues aside for the purpose of this discussion. How does a service provider handle the requirement to meet a law enforcement agency with their wiretapping needs? The logistics and technology can be exerting, annoying and business-wise, even prohibiting. As I just mentioned somewhere else, I should probably point out that if I was a major ISP often asked to answer the call of law enforcement with legal wiretaps, this could be very annoying as well as technologically a killer to my network architecture. Just sticking some hub somewhere in my network may not cut it, and will certainly not cover all of the communication. What about different lines and locations? As a large provider, AT&T probably had to find better solutions to the call of the law, or reply on the law's technology to not kill their business. This indeed happened before. As some of you may remember, according to one NANOGer at the FBI's Carnivore presentation a few years ago, "sticking" just such a hub is what caused his network to break-down. Creating a centralized wiretapping point under strict security may be just the thing to both comply and save costs, not to mention staying on the air. I don't see how that _by_itself_ is wrong of AT&T. There are other issues here as well. The Internet Infrastructure in a significant way sits in the US. We all know that. Is it really a surprise to anyone that the NSA, which states it listens to the Internet, is using a local resource such as that on US soil? They would be crazy not to. They rivals and enemies in other countries certainly won't think twice. There is the issue of separating domestic communication from the rest, but that's just something they have to deal with and US citizens have to be paranoid about. This whole situation will probably result in better supervision/monitoring of activities rather than stopping any of them (i.e. simply more people in-the-know of what the NSA is up to). That said, I am not a US citizen nor up-to-date on the details of this ATT/NSA issue or the privacy implications, and I am sure enough of the US folks here are. Gadi.

10 15

Re: ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]
by Martin Hannigan 24 May '06

24 May '06

At 04:58 AM 5/24/2006, Michael.Dillon(a)btradianz.com wrote: > > >The NANOG meeting archives are full of presentations as the result > > >of very sophisticated network monitoring. Like most technology, > > >it can be used for good and evil. You can't tell the motivation > > >just from the technology. > >OK, so he says in a roundabout way that you are >already paying for some sophisticated network monitoring >and it probably won't cost you much to just give >some data to the "authorities". > > > Sean, please drop this subject. You have no experience here and it's > > annoying that you keep making authoritative claims like you have some > > operational experience in this area. If you do, please do elaborate > > and correct me. From what I understand from the folks at SBC, you > > did not run harassing call, annoyance call, and LAES services. I would > > appreciate a correction. > >Huh!?!?!? >Are you saying that people should buzz off from >the NANOG list if they change jobs and their latest >position isn't operational enough? Are you saying that >people should not be on the NANOG list unless they >have TELEPHONY operational experience? > >What is the world coming to!? [ rescued from the killfile ] As far as archives being chock full of information, Chip Sharp of Cisco made a factual presentation on CALEA years back. The rest of the "discussion" has been mostly hyperbole. Emotional fodder on political agendas instead of technical, operational, or otherwise. I'd characterize 90% or more of it as junk. If I want to read about politics, I can open my newspaper with my coffee - and I do, but that's the extent I need to see it all day long. We're already bombarded with this stuff elsewhere. No, someone should not quit NANOG's list because they change jobs. Changing jobs has nothing to do with it. Being a subject matter expert is. It's arguable who the SME's here on the list are related to CALEA. There aren't more than 2 or 3 and they aren't usually talking about these types of posts. Not because there's a big secret to be kept. There isn't. It's all public. It's because the thread will always turn to politics and disinformation and it's a bad use of everyones time. Perhaps a bit too harsh on the prior response, but the "quality" of some of the posting here has become arguably low as of late. Maybe it's because of too much rain? I don't know, but NTP, geo-location, and CALEA have all been subject to this. /me back to our regularly scheduled programming >--Michael Dillon -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan(a)renesys.com

1 0

MAE-WEST - 55 S Market area equipment sourcing
by Rodney Joffe 24 May '06

24 May '06

Sorry for the noise, but this is sorta operational (for me anyway ;-)) We are physically in the process of configuring the connectivity for NANOG 37. "We" are from "out of town" ;-) It has not been easy (when has it ever been?). Accept the following: We have to transit some existing infrastructure that is restricted to 100Mb FE over Copper with RJ45 connectors. On one side, we have to connect the FE connection to a Gbic equipped router over existing single mode, with either an SC or FC connector (the patch panel accepts either of these). On the other side of the link we have to connect the FE connection to a Gbic equipped router over existing multimode mode, with an ST connector (the patch panel accepts only this) Can anyone point me to a source in the 55 S Market area that might have the appropriate intelligent media conversion devices actually in stock, at a reasonable price, and not "1-2 days" out? Bearing in mind that besides converting media, I have to convert speed for the Gbics? And I am trying to avoid the cost of getting two switches, and installing appropriate Gbics in them :-/ Thanks /rlj

3 2

41/8 announcement
by Ernest B. M 24 May '06

24 May '06

Apologies for duplicates] Dear Colleagues, Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. Reachability tests can be conducted with 41.223.252.1 as a target IP address. Kind Regards, Ernest, AfriNIC.

3 2

[Way OT] Re: Geo location to IP mapping
by Scott Weeks 23 May '06

23 May '06

----- Original Message Follows ----- From: Jeff Rosowski <rosowskij(a)ie.ymp.gov> > > I just tried that, says I'm 100 miles south of where I > > really am. That's quite a long way out in a small > country like England. > > Only 100 miles? I entered the address of a box I have in > Virginia, and it says it's in California. Well at least > it got the country right. One of the geolocation thingies said my addresses were in Amsterdam. That's only 10,000 miles from Hawaii. 2500 miles more and that's exactly the opposite side of the planet... ;-) scott

5 4

RE: private ip addresses from ISP
by Andrew Kirch 23 May '06

23 May '06

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > David Schwartz > Sent: Wednesday, May 17, 2006 1:37 PM > To: nanog(a)nanog.org > Subject: RE: private ip addresses from ISP > > > > > Our router is running BGP and connecting to our > > upstream provider with /30 network. Our log reveals > > that there are private IP addresses reaching our > > router's interface that is facing our upstream ISP. > > How could this be possible? Should upstream ISP be > > blocking private IP address according to standard > > configuration? Could the packet be stripped and IP be > > converted somehow during the transition? It happens in > > many Tier-1 ISP though ! > > > > Thank you for your information > > Do you mean: > > 1) You are seeing BGP routes for addresses inside private space? > > 2) You are seeing packets with destination IPs inside private space > arriving at your interface from your ISP? > > 3) You are seeing packets with source IPs inside private space > arriving at > your interface from your ISP? > > If 1, feel free to filter them. You ISP probably uses them > internally and > is leaking them to you. Feel free to complain if you want. > > If 2, make sure you aren't advertising routes into RFC1918 space to > your > ISP. If not, you should definitely ask them what's up. > > If 3, that's normal. These are packets your ISP received that are > addressed > to you and the ISP is leaving to you the decision of whether to accept > them > or not. Feel free to filter them out if you wish. (It won't break anything > that's not already broken.) Sorry to dig this up from last week but I have to strongly disagree with point #3. >From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. The ISP shouldn't be "leaving" anything to the end-user, these packets should be dropped as a matter of course, along with any routing advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space into my network piss me off, and get irate phone calls for their trouble. Andrew

6 7