September 2001 - Test - lists.nanog.org

World Trade Center attack
by Greg Pendergrass 11 Sep '01

11 Sep '01

Both towers of the World Trade Center are burning after planes flew into them in an apparent suicide attack. Many people are certainly dead. I don't give a damn what network disruption this causes, but please say a prayer for those killed. Greg Pendergrass

1 0

RE: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
by Hire, Ejay 10 Sep '01

10 Sep '01

Em... I hate to be the bearer of bad news here, but I expect the Provider-in-the-middle isn't using NAT, They are probably using RFC 1918 Ip space for Transit links. This does not necessarily imply that they are using Nat. Using RFC 1918 space inside a network on transit segments that will be passing data but not generating it makes sense. No-one really needs to be able to Ping/SNMP-Query/http attack my routers serial links. using RFC 1918 space on these links precludes that possibility because my interfaces are not addressable on the public internet. Comments: -----Original Message----- From: bmanning(a)vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Friday, September 07, 2001 8:56 PM To: andy(a)xecu.net Cc: bicknell(a)ufp.org; nanog(a)merit.edu Subject: Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...) > Can you show damages in the situation of email? Yes. With packets? No. And > before you come back at me with some crazy convoluted contrived scenario, > let's just realize how far off the beaten path we are at this point. If > your ISP is going to force you to use NAT, "against your will", get a new > fricking provider. For that matter, what ISP NATs you against your will? Not quite so friend Andy. Someone in UAE claims that I sent porn to them. And investigation shows that not only is there a NAT one hop away from the purported victim, there is -another- NAT in the path, injected by some intermediate ISP as well as the one injected by my provider. Now I can chage my provider to one w/o NAT. I can even get the PV to change their provider (well maybe, given they are in UAE) But how can we avoid the intermediate ISP that is in the transit path? And can I persuade the judge that since NATs are known to muck about w/ addresses & such that I can construct a case that what was received did not come from me. So the porn came from one of the NAT operators. > > Andy Dills 301-682-9972 > Dialup * Webhosting * E-Commerce * High-Speed Access >

6 5

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...
by Scott Gifford 10 Sep '01

10 Sep '01

miquels(a)cistron-office.nl (Miquel van Smoorenburg) writes: > In article <F5F3FBBFC94DD4118E4500D0B74A095F013E70E1@EMAIL2>, > Hire, Ejay <Ejay.Hire(a)Broadslate.net> wrote: > >Using RFC 1918 space inside a network on transit segments that will be > >passing data but not generating it makes sense. > > Only if the MTUs on all interfaces of the routers are the same. > Otherwise you might generate a ICMP size exceeded message that > will never reach the sender, breaking Path MTU Discovery. Not to get involved in the RFC1918 for routers topic again, but the NAT discussions here got me wondering if much of this could be solved by having an edge router translate all of the internal router-network addresses to some constant, real address. Setting aside opinions about the brokenness of NAT, can anybody think of anything this would break? -----ScottG.

1 0

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: Sunday, September 09, 2001 5:42 PM |> Unfortunately, I let my urge to smack Meyer down mask the |> original intent of my message. For a young whipper-snapper, you're awfully full of it^H^Hyourself, ain't ya?

3 2

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

10 Sep '01

Roeland Meyer <rmeyer(a)mhsc.com> writes: > |> 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". 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. 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? I ask not to drag this discussion on, but because I use NAT for address conservation and security on a couple networks that I operate, and am curious if I'd be much better off with something different... -----ScottG.

6 6

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

10 Sep '01

Roeland Meyer <rmeyer(a)mhsc.com> writes: [...] > 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. The rest of what you're saying makes sense, but I just don't buy this... A clever design might allow NAT to work with all protocols and in both directions, which would have increased connectivity but decreased security. But how would it get onto my network without me putting it there, and presumably configuring it securely? The box doing NAT is under my control... ----ScottG.

1 0

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