- NANOG - lists.nanog.org

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 10 Sep '01

10 Sep '01

|> From: Scott Gifford [mailto:sgifford@tir.com] |> Sent: Monday, September 10, 2001 10:30 AM |> |> Roeland Meyer <rmeyer(a)mhsc.com> writes: |> > Any current protection is strictly the |> > result of a side-effect. The side-effect that breaks the internet |> > connection. It's a result of the connection being broken. |> > A properly built |> > firewall is much more effective and definitely more |> > deterministic. Neither is it vulnerable to a "fix patch". |> |> I don't understand what kind of "fix patch" you're talking about |> here...NAT uses the same techniques that a stateful firewall uses; if |> you can find some kind of "fix patch" to bypass NAT, chances are |> excellent it will work on a stateful firewally, too. Mot so. What is needed to truely fix NAT is to propogate the translated addresses, both ways. This would give you an address product like <Inet addr>:<NAT addr>. The problem is that almost no stack, that I know of, can deal with such a form. The reason NAT works is that you only lose one side and the other side doesn't know that you've lost it. |> I've actually seen the question of how NAT breaks the Internet more |> than a good stateful firewall come up more than once, and haven't |> really seen a satisfactory answer. Where does a stateful firewall |> configured to only allow outgoing connections work that NAT doesn't? The difference is determinism. You control, to very fine detail, how a firewall works. Things that don't work are intended to not work. Firewalls aren't accidents. NAT address propogation failures are, they are not consistent, and can't be relied upon to continue. Who knows, some genius, somewhere, may fix it tomorrow. Lord knows, there is sufficient incentive to do so. If that happens, your security is toast, if all you are relying on is NAT, rather than putting up a real firewall.

2 1

Re: Where NAT disenfranchises the end-user ...
by Scott Gifford 10 Sep '01

10 Sep '01

Randy Bush <randy(a)psg.com> writes: > > Not exactly, in your scenario you are counting on the firewall to block > > hostile traffic destined for some ips. If they are Natted, it is more > > work to compromise those stations. > > and if you change your name you are less likely to be mugged. I think that most of this discussion has been about not just straight address translation, but NAT with port translation. If you're using address and port translation, the analogy goes more like "if you never leave the house, but instead go through the same motions while sitting in your house, while a robot performs your actions out in the real world, you are less likely to be mugged." Which is true, if somewhat of a dull existence... ----ScottG.

1 0

RE: Where NAT disenfranchises the end-user ...
by woody weaver 10 Sep '01

10 Sep '01

I'm not sure who was first, in terms of IOS NAT and ip_masq. If memory serves (and it usually doesn't) then 11.2 was released around Aug 97. I don't see any easy way to identify the release date. However, I think the linux code is older, although of course its largely based upon the BSD firewall code. The online source log shows 38 * Masquerading functionality 39 * 40 * Copyright (c) 1994 Pauline Middelink 41 * 42 * The pieces which added masquerading functionality are totally 43 * my responsibility and have nothing to with the original authors 44 * copyright or doing. 45 * 46 * Parts distributed under GPL. 47 * 48 * Fixes: 49 * Pauline Middelink : Added masquerading. 50 * Alan Cox : Fixed an error in the merge. 51 * Thomas Quinot : Fixed port spoofing. 52 * Alan Cox : Cleaned up retransmits in spoofing. 53 * Alan Cox : Cleaned up length setting. 54 * Wouter Gadeyne : Fixed masquerading support of ftp PORT commands 55 * 56 * Juan Jose Ciarlante : Masquerading code moved to ip_masq.c But Cisco was promoting NAT much earlier. They bought the old NTI hardware (now called the PIX), and its primary purpose in life was NAT -- the company was called Network Translations Inc. Looks like my first PIX install was 3 July 1996, so that predates IOS installations, I think. --woody On Sunday, September 09, 2001 6:22 AM, Circusnuts wrote: > > Yep- NAT showed up in Cisco IOS in the 11.2 version. I am [..] > ----- Original Message ----- > From: "Adam McKenna" <adam-nanog(a)flounder.net> > Sent: Friday, September 07, 2001 3:31 AM > Subject: Re: Where NAT disenfranchises the end-user ... > > > On Thu, Sep 06, 2001 at 10:29:21PM -0700, Roeland Meyer wrote: > > > > > > ip_masq started out as a cheap way to cheat ISPs that > wouldn't allocate > IP > > > addrs to dial-up users (home users have no need for a > LAN?), or wanted > to > > > charge an arm'n'leg for every IP addr. This irked the > Linux community > > > sufficiently that they wrote a "cure". Unfortunately, the > popularity of > the > > > "cure" superceded the need. > > > > Erm, sorry, but NAT was alive and well on Cisco routers > long before it was > in > > the Linux kernel.

6 5

FTP Probes from Taiwan/China
by Gordon Ewasiuk 10 Sep '01

10 Sep '01

Has anyone seen a dramatic increase in FTP probes/scans/bad stuff from certain IP blocks in Taiwan or China? Specifically, 211/8, 61/8, and 202/7. I'm logging over 7500 probes/hr right now. Is there a new exploit out or something? Another network just surfaced: 210.82/15 -Gordon -------------------------------------------------- Gordon Ewasiuk, Certifed Sun Fanatic, Winstar VHC The REAL office number is here-----> 703.893.4901 Tired of BSODs, My Computer, and Code Red? http://www.sun.com/solaris/binaries/ -------------------------------------------------

4 5

configuration lost
by Nour Rabii 10 Sep '01

10 Sep '01

hello , my 7513 lost configuration , i don't know why ? i have something like : Rbackbone#wr startup-config file open failed (Device or resource busy) Rbackbone#sh startup-config Using 35806 out of 126968 bytes %Error opening nvram:/startup-config (Device or resource busy) Best regards .

5 4

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 10 Sep '01

10 Sep '01

|> From: Jared Mauch [mailto:jared@puck.Nether.net] |> Sent: Sunday, September 09, 2001 2:49 PM |> Let me reprhase my inital statement, "In most cases i've seen |> where someone is using NAT it's part of a security policy and not due |> to lack of available address space". Jared, those whom depend on an accident, for security, deserve what happens when the accident undoes itself. I was just over on www.netcraft.com, checking out their stats for the CodeRed worm. I was amazed at how fast IIS admins responded by applying the patches. If NAT were suddenly "fixed", any incidental security is toast. NAT was never designed for, and was never intended as, a security method. Any current protection is strictly the result of a side-effect. The side-effect that breaks the internet connection. It's a result of the connection being broken. A properly built firewall is much more effective and definitely more deterministic. Neither is it vulnerable to a "fix patch".

1 0

IDC management software
by Benjie Ko 10 Sep '01

10 Sep '01

Hello, I dont know if this is the right list to email this. No flames please. For those who are operating IDCs or server farms, what software do you use to monitor/manage your client's server farm. Monitor includes latency,bandwidth usage,cpu/mem/disk usage. Also, any providers for a DS3 connection colocated at 1 wilshire in LA (email me privately for this)? Regards, Benjie __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com

1 0

once again: RE: Where NAT disenfranchises the end-user
by Roeland Meyer 10 Sep '01

10 Sep '01

|> From: Adam McKenna [mailto:adam-nanog@flounder.net] |> Sent: Friday, September 07, 2001 4:49 PM |> I realized that the NAT argument is just a smokescreen which |> enables Meyer to |> continue his prefix filtering flamewar. The sooner you all |> stop paying |> attention to him, the better off this list will be. Aside from the fact that you seem to have some personal grudge. You are wrong. For one thing, this was, until now, far from flamewar. What you have done, however, is akin to invoking "Nazi". You may not care that NAT issues are restricting the distribution of ICANN's deliberations, but many other do. Folks here may not like H.323 but it is, unfortunately, the best tool we have. Those that can't afford to have static IP addresses will not be able to participate fully. FYI, the Montevideo sessions are going on now. Travel expenses are onerous and telephony expenses are almost as bad. VOIP is the only means that we can do global participation, at reasonable expense and within ICANN budget (cheap) whilst not bankrupting the participants. Client applications are almost universally available, at little to zero cost. Server-side code is widely available as open-source. The only thing mucked up is the stuff in the middle. Sir, that involves network operations, by ANY stretch of the imagination, and bringing that point up is not flamewar. If you can come up with something better then do so. BTW, I think it's a rotten shame that the major ISPs aren't doing something to help with this. I'm not talking about donations to ICANN either. I'm talking about resources, connectivity, and other sorely needed assistance. There should be no reason that the Berkman Center is the only resource provider. Except for randy, mike, patrick, and very few others, you guys have your very own constituency fercrisakes and y'all aren't doing squat! "I gave at the office" ain't cuttin' the mustard. No one behind a NAT boundary can participate in the online meetings (the info of which was sent in my original message, forwarded from the DNSO-GA). That we took a few detours, in these discussions, is the nature of unmoderated group discussions. Certain operational policies are hampering the business development of the internet. They break the Internet. 1) UDRP and uncertainty over DN ownership (being addressed in ICANN/DNSO). 2) Anti-mailer relay activities eliminate certain business models. 3) Instability and unreliability of access makes business nervous (NorthPoint, ATT-CA?) 3a) NAT breaks end2end connectivity with end-users (see H.323 for examples). 3b) lack of true multi-homing capability. 3c) routing issues 3d) etc. If I may don my marketing hat for a mo; from what I'm seeing, VOIP conferencing may be the next killer-app of the Internet and may be the ONLY thing that'll let anyone else play evenly with the ILECs. Like firearms, it levels the playing field, for the little guys. It also does in the IXCs, unless they go there first. So, unless you can come up with something better than H.323, I suggest that we find means to support it rather than breaking it further. NAT is a rather largish problem here. Unless, of course, you *like* the current economic climate. This is not intended as a rant or a flame. Those who feel otherwise, can complain directly to me. -- R O E L A N D M J M E Y E R Managing Director Morgan Hill Software Company tel: +1 925 373 3954 cel: +1 925 352 3615 fax: +1 925 373 9781 http://www.mhsc.com

4 3

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 09 Sep '01

09 Sep '01

|> From: Eric A. Hall [mailto:ehall@ehsco.com] |> Sent: Thursday, September 06, 2001 9:49 PM |> > "Charles Sprickman" <spork(a)inch.com> |> |> > NAT has it's place, and we have many happy customers that are quite |> > pleased with their NAT'd connections; some simple, some fancy. |> |> NATs are a band-aid. ip_masq started out as a cheap way to cheat ISPs that wouldn't allocate IP addrs to dial-up users (home users have no need for a LAN?), or wanted to charge an arm'n'leg for every IP addr. This irked the Linux community sufficiently that they wrote a "cure". Unfortunately, the popularity of the "cure" superceded the need. |> > What irks me more than NAT are crappy protocols like FTP |> and H.323 that |> > make too many assumptions about how much of my machine I |> am willing to |> > expose in order to communicate using these protocols. |> |> FTP was designed for ARPANET, H.323 was designed to work |> over ANY packet |> network. Neither of them were designed for TCP/IP in particular. FTP has well outlived it's usefullness. There are better alternatives. It was a good experiment...on how we shouldn't do some things. NDAs stop me from commenting about H.323. Just know that every SuSE Linux 7.2 distro comes with www.openh323.org and www.opengatekeeper.org software, complete with instructions on interfacing it with NetMeeting3. No, it won't work across NAT boundaries. |> They don't break the end-to-end design principles though. |> Neither do network games, chat tools, and other |> peer-to-peer protocols that run in elected-server |> or server-to-server modes. Damn, more NDA problems <g>. It is sufficient to state that one of the challenges facing p2p projects is presented by the large NAT population. Actually, dynamic IP isn't so good either. But, we are getting around that with LDAP directories. The real problems arise when two clients report the same RFC1918 address to the directory. If both are behind a single NAT'd IP then it gets really fun. |> The fact is that I can write an Internet-compliant |> application in about two minutes that will break every |> NAT ever sold, simply because they don't have a |> proxy for the protocol. NATs violate fundamental Internet |> principles. They were broken from the start. Agreed. It is all fine and dandy to say what developers should and shouldn't do. Rarely, are those practicing such refined methodology, actually writing the code or paying for same. Market needs drive business requirements, which drives code, which drives operations, which *may* drive more market needs. NAT was an answer to a market need that operations wasn't fulfilling. The pent-up market demand for multi-homeing may drive solutions that the operations community may not like. Guys, this is easy. Start accepting prefixes out to /24 like you are already getting paid to do. Then ARIN can start selling /24s and matching ASNs, like they should. Yes, you might lose some revenue from IP addr sales, but the alternatives might be less desireable.

9 9

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 09 Sep '01

09 Sep '01

|> From: Jon Mansey [mailto:JMansey@interpacket.net] |> Sent: Thursday, September 06, 2001 11:41 AM |> |> Isnt part of the solution here for ppl to write NAT-aware |> applications? |> |> I got this idea from a bugtraq post about gnutella that is able to |> detect and announce a different IP address than that of its actual |> private host IP based on what its internet-facing public IP is. |> |> Im sure there are a host of reasons why this is not a good idea from |> a security POV, but its a start, no? |> |> Im not disputing that a NATed connection should not be sold as "full |> Internet connectivity", I agree, but in terms of making it look and |> feel like one, I think we're close. Two software development houses, playing nice with each other, is more rare than two ISPs doing same. The bottom-line is that it comes right off the bottom-line. You can't deny that it's extra work/cost and effects time-to-market. Remember, in software development, it's the second 90% that kills the project. Consider the straw that broke the camel's back. Then consider that 80% of all software projects never make it to market. Then consider that most developers are NOT network engineers. They expect the network to *be there*, period.

8 7