May 2006 - Test - lists.nanog.org

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

Re: private ip addresses from ISP
by Joe Maimon 23 May '06

23 May '06

Robert Bonomi wrote: >>Date: Tue, 23 May 2006 11:14:53 -0400 > > "Translating" those addresses is a *BAD*IDEA*(TM). That obscures who > the reporting machine was _if_ you have to actually communicate with that > network operator. > These are the options: Construct the network so that icmp is never sourced from rfc1918 OR Do either of below: Filter icmp sourced from rfc1918 on egress Dont filter icmp sourced from rfc1918 on egress Translate icmp sourced from rfc1918 on egress Use some feature that translates/replaces rfc1918 sourced icmp with nonrfc1918 identifiable internally. > This is exactly why RFC1918 says that private-addrss source packets _should_ > _not_ be passed across enterprise boundaries. It does _not_ say 'must not', > because there *are* situations where it is necessary. This _is_ one of them. :) You are in favor of: Dont filter icmp sourced from rfc1918 on egress However that leads to a significant hole in "anti spoofing defense sheild" of the net. So it becomes difficult to be in favor of this and also claim that liberal application of anti-spoofing/urpf will solve most of the abuses which depend on spoofing to be effective. > > >>Understandably, translation on providers networks is not always feasible. >> >>A feature on routers that sourced icmp packets to be told specificaly >>which address of the router to source it from would also help. > > > When the router has only RFC1918 addresses (totally internal to the network), > it doesn't matter/help. In this instance they would assign a single or more address nonrfc1918 to leverage this feature. > > Also, the address to use as the source _is_ well-defined. it is the interface > the packet came in on that triggered the ICMP message. The proposed feature would make it configurable, perhaps on a per interface basis. The provider would keep an internal database. It need not even be routed. It would be nice if this was completely an icmp packet field value and not dependant on the ip header to identify the icmp generator.

1 0

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

23 May '06

> 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. > 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.) It's even more comical when the NSP uses RFC1918 space internally, and does *not* filter those source addresses from their customers. > 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. Some of us, on the other hand, _do_ object. YMMV

3 2

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 > Robert Bonomi > Sent: Tuesday, May 23, 2006 9:22 AM > To: nanog(a)nanog.org > Cc: davids(a)webmaster.com > Subject: Re: private ip addresses from ISP > > > > 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. > > 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.) > > It's even more comical when the NSP uses RFC1918 space internally, and > does > *not* filter those source addresses from their customers. > > > 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. > > Some of us, on the other hand, _do_ object. > > YMMV > Well said, I think that Robert has done a phenomenal job of summing up my point. I don't want this trash on my network. The pertinent RFC says it shouldn't be entering my network from *your* network (for varying values of your). I don't buy the argue that the end user should decide what traffic they do and don't want when the RFC states unequivocally that the traffic shouldn't be there. Even reasonably large networks are often run by people with no appreciable networking experience, MCSE, MCP MCP+I etc. This is a simple fact of life. Andrew

1 0

AS9132 filtering my traffic (41.220.0.0/20)
by Richard Mikisa 22 May '06

22 May '06

Hi all, Anyone from AS9132 - Broadnet mediascape communications AG, Hamburg on this list? Please get back offline. Seems like you are blocking all traffic from 41.220.0.0/20 - AS29032. All attempts for help via email and phone have failed. -- Richard

1 0

snfc21 sniffer docs
by John Kinsella 22 May '06

22 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

1 0