- NANOG - lists.nanog.org

RE: rfc 1918 (why filtering is a good idea for non-transit organi zations)
by Mathew Butler 23 Feb '01

23 Feb '01

Actually, if memory serves me correctly (for once), there was a situation several years ago where a transit provider ran out of bandwidth and started shunting traffic through a (better-connected) customer's network. If filtering had been operating properly at that time (if there had been enough CPU muscle in the routers) as specified below, then this could NOT have happened -- the customer's network would have recognized the destination IP as not being within its address range, and filtered it on ingress. (Or, it could have checked the source IP, and if it wasn't in its address range, filtered it on egress. My personal opinion is that both are necessary and desirable, for different reasons.) -Mat Butler -----Original Message----- From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] Sent: Friday, February 23, 2001 2:19 AM To: Mark Radabaugh Cc: North America Network Operators Group Mailing List Subject: RE: rfc 1918? This only can apply to small networks, specifically stub networks, if you're carrying transit or have multiple connections out you'll find filters which only allow your own ips in and out start dropping a whole lot else! But i think you have the right idea, filters should be applied at the provider edge to such stub networks and then no nasty ips will get through to the provider network and hence the internet. Oh, and I dont think I showed my opinion on my last mail, i think use of 1918 on p2p is wrong! But.. as so many large networks do it you cant just filter it out and assume everything will work. Steve On Thu, 22 Feb 2001, Mark Radabaugh wrote: > It is my intention to avoid having 1918 addresses leaving my network. > > At our egress points the filters are fairly short -- they allow only traffic > with our IP source addresses to leave. This was my interpretation of the RFC's. > Some in this discussion seem to be saying that we should also filter for RFC1918 > destinations. Am I reading this correctly? > > I can see that packets destined for RFC1918 addresses will leave our network > (due to default routes) but are promptly dropped at the first BGP speaking > router they encounter. Is it worth the extra router processing time to check > all outgoing packet destinations as well? I can't see where this extra > filtering is worth the trouble. > > Mark Radabaugh > VP, Amplex > (419)833-3635 > mark(a)amplex.net > > > > >

1 0

DS3 Ordering Experiences
by Andy Dills 23 Feb '01

23 Feb '01

This might help some people ordering DS3s from UUnet in the future, so I'll post it here for the archives. We ordered a DS3 to UUnet last July, and after several blown FOC dates, we finally started passing packets last night. (And man, nothing like 2 ms latency and being able to measure downloads in MB/s.) Thank god the circuit is quality, or this would be an entirely different post. UUnet was amazingly slow: 7+ months to terminate a DS3 to Frederick, MD, 50 miles north of their world headquarters. The main reason they were so slow is because of the way they tried to design the circuit. They have various 'legacy' systems (worldcom isn't one big happy family) that they must check with to determine if they have the proper capacity to bring the circuit to your location. Checking with each of these legacy systems takes up to 21 days or even more. And here's the fuckup: They check each one serially, instead of all at the same time. So, with us, they hit worldcom, mci, and mfn (I believe) before they realized they don't have the capacity, and had to contract AT&T. They didn't contract AT&T to backhaul our circuit until DECEMBER. The entire time from July to December, they were checking with their legacy systems to determine if they had capacity. Had we told them to check all three at the same time, we could have saved 2-3 months. So, some things we have learned from this experience, that I would like to pass on to future people: 1) If you are not in a metro area, and are ordering a circuit of any sort with UUnet (or that touches Worldcom in any way), demand up front that they check all of their legacy systems for capacity at the same time. Request to be informed of the completed circuit design within 30 days. 2) Escalate early and often, and be aggressive. Give them a chance to deliver the circuit design, but if the circuit design isn't done in 30 days, escalate every three days until it's done. 3) Every time they miss a FOC date, escalate two levels. Believe me, once you start annoying the VPs, things start to happen _real_ fast. 4) Be an asshole when you order the circuit with regard to the SLA; demand that for every month after 90 days that the circuit is on order (but not installed), you get a free month of service. So, it was the world's biggest pain in the ass to bring up, but now that it's installed, I love it. <does the bandwidth dance> Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

4 4

RE: rfc 1918?
by Chris Davis 23 Feb '01

23 Feb '01

My incident started the thread. The packets are not even an irritant; I was just curious as to why the rfc1918 addresses were being logged by my ingress filter. Now I know- General Practice dictates that my filters on my stub network are the appropriate place to filter out the private addresses. I had always believed the private addresses to be "non routable" (ie handled by ISPs) but that seems to be at least partially incorrect. Thanks to everyone who discussed! Hopefully this thread shed some light for some other people regarding the difference between the way things work in theory and in practice. My apologies to Mr Steenbergen who seemed very, very distressed about seeing this topic. -----Original Message----- From: Mark Borchers [mailto:mborchers@splitrock.net] Sent: Friday, February 23, 2001 9:46 AM To: 'nanog(a)merit.edu' Subject: RE: rfc 1918? > This is not an issue of paranoia (except for those who actually use > PRIVATE addresses internally and have properly configured > their gateways > to be paranoid about even seeing such packets, let alone > routing them). Unless I'm mistaken, a prime reason for the evolution of RFC 1918 addresses was that it was once common practice for people to help themselves to PUBLIC address space to use on PRIVATE networks. As the world got more connected, these addresses occasionally got leaked and caused address conflicts. Using RFC 1918 addresses prevents conflicts with public/registered space. Obviously the possibility of leakage still exists, but with RFC 1918 the havoc potential is diminished to a mere irritant level. Which is what the incident that started this thread appeared to be.

1 0

History of private peering and exchanges?
by Howard C. Berkowitz 23 Feb '01

23 Feb '01

Between fading memories and NDA's, it can be hard to track how things happened...but I'm trying to put together some timelines about interprovider peering both through private peering (i.e., at what point it became economic to meet other than through ARPANET/NSFNET) and at exchanges. In the beginning, of course, there was the ARPANET. Then there was the NSFNET. The NAPs were the first recognizable exchange points, with AUPs. NAPs were linked by VBNS. CIX came later, without the AUP restrictions of NSFNET. My impression is that bandwidth into it, at first, was quite limited. At some point, there started to be a business case for large providers to interconnect with bilateral private links as well as at exchanges. When did such links first get used for commercial traffic? In the beginning, were they short-haul connections between cages in exchanges, or WAN links between major provider hubs? I'm referring here only to interprovider links, not to transit customers. Also in the timeline was the advent of true "local" or "metro" exchanges. Going through the archives, the first I see was Tucson. Was that indeed the first cooperative exchange intended to reduce backhaul?

4 4

Re: rfc 1918?
by Richard A. Steenbergen 23 Feb '01

23 Feb '01

On Fri, Feb 23, 2001 at 12:32:11AM +0200, Ariel Biener wrote: > > On Thu, 22 Feb 2001, Greg A. Woods wrote: > > > This gets us back to the discussin we had here about 3-4 months ago > about what should be done in order to create a friendly internet > environment, that is, where every Internet connected entity actually > gives a damn about everyone else. We go through this every couple months, and the same conclusion is reached every time. The psycho paranoid people like Greg Woods and Eric Hall scream that any RFC1918 sourced packet on the internet is a sign of the apocalypse, and you must apply packet filters to stop them from going out and coming in. Most everyone else just doesn't care, and realizes that yes it's a packet you won't be able to reply to but the world will not end if a few of them are floating around on the internet. There is far worse traffic floating about then an RFC1918 packet because of someone's misconfigured NAT, and they will probably proceed to FIX IT when they can't communicate with the rest of the world through it. Yes sometimes there IS communication from sources where we DO NOT want a reply back, like the ICMP messages generated by a router. It might be a better practice to simply put them in a section of allocated but unannounced IP space to avoid the 1918-nazi's, but thats another story. If you have your own 1918 space and you are worried that there might be some mysterious conflict, then by all means filter them from your ingress connection the same way you should filter ALL packets sourced from your ip space. Now can we please let it go? -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 4

Re: rfc 1918?
by Rancken 23 Feb '01

23 Feb '01

On Thursday, February 22, 2001 10:14 PM, Valdis.Kletnieks(a)vt.edu (Valdis Kletnieks) wrote: That's probably optional. But if you have the router resources to do it. every little bit helps. You probably should filter and log it, to find out why one of your hosts is trying to send to a 1918 address outside your site - if you're not using 1918 space, it shouldn't happen, and if you ARE using it, the packet should have ended up inside your net, not on your border router. Which is quite true, but there are a lot of people out there still using hubs, which (along with improperly configured NATs) probably explains the origins of a lot of this traffic. Which brings me to my point - some of us are actually grateful for having our Private (pun intended) packets filtered while we were setting up a network. John T. Rancken II Rancken(a)Atlantic.net (which is my isp, not where I work :).

1 0

Beer and Gear (Last one by me)
by Ukyo Kuonji 23 Feb '01

23 Feb '01

There is nothing in the Charter that states that I am out of line, nor does it specify a method of removing me from the list. I am not going to continue to carry this any farther, I just want to be certain that the membership knows what is going on. If the membership chooses to be sheep, that's fine. I will leave that alone. Since the Charter does not specify any procedure to modify the operation of NANOG, any action to do so, unless supported by the membership would be handled by the US courts. I am not willing to take that action, nor do I think it needs to be taken. If the membership chooses my proposed option #3, then that's good enough for me. UK PS, Don't insult me by trying to apply filters. I'd just find another way to get through if I wanted to, which I don't. </asshole> --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. On Feb 22 Danny Wrote: Oh, you don't want to play politics but you're certain we need more politics. Actually, you know, perhaps that would be good. Then the membership could vote to tell you that you've been heard, now it's time to shut up. -danny _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

4 3

Re: rfc 1918
by Jim Shankland 23 Feb '01

23 Feb '01

Note that the proposition, "Providers should filter RFC1918-sourced packets at the periphery" is a subset of the proposition, "Providers should filter at the periphery packets with source addresses not explicitly authorized by the provider." I subscribe to the second proposition, and hence implicitly to the former. The problem is not the stray RFC1918-sourced packet here or there. The problem is that the de facto standard is that you can inject packets with arbitrary source addresses into the Internet from anywhere. The number of attacks that use spoofed source addresses is reason enough to change this. But I'm not holding my breath. Jim Shankland

2 1

rfc-1918 has been godwin'd please stop thread...
by Rich Sena 23 Feb '01

23 Feb '01

Folks I distinctly heard a nazi in there... -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

1 0

Re: Network for Sale
by Steven M. Bellovin 22 Feb '01

22 Feb '01

In message <038901c09d22$d2736280$7c4cf9d1(a)geeksparadise.com>, "davids" writes: > >> And how does "delay" differ from RTT, except for the obvious constant >> factor? >> >> --Steve Bellovin, http://www.research.att.com/~smb > > The RTT is the sum of two delays. There is no simple way to separate >the two. In general, you don't even know what path the return packets are >taking. This same problem applies to trying to measure packet loss and using >the results to influence routing decisions. I understand that, of course, but since the return path is used for the ACKs that clock the transmissions, I suspect that it's a fair approximation. Paul's response to my posting was quite fair, in fact. --Steve Bellovin, http://www.research.att.com/~smb

1 0