RE: To CAIS Engineers - WAKE UP AND TAKE CARE OF YOUR CUSTOMERS

From: John Fraizer [mailto:nanog@Overkill.EnterZone.Net]
Sent: Monday, May 14, 2001 1:33 AM

On Mon, 14 May 2001, Roeland Meyer:

> Yet, I can't depend on IP addrs because my upstream might have to be
> changed... damn, I shouldn't have depended on my scumbag
DSL upstream, eh?
> Gee, maybe I should have had a names based system after
all? Either way, I
> wind up having to rebuild Oracle boxen and application
servers, every time
> somebody farts. Just what in blue hell are we supposed to do?

Um, lets see...how about this. You use NAT. That'll be
$180.00 please.
I'll send you an invoice.

Good luck, some critical stuff can't NAT. Send it, I'll file it in the
appropriate receptacle.

> BTW, the last I checked SSL certs are usually names based.
Pretty slack security, eh?

Slack, no. You're comparing apples to oranges here and
HOPEFULLY, you know
it. Basing security on IN-ADDR is absolutely idiotic.

Agreed, but some code requires it. Which was my point. I'm talking smaller
vendors, like Oracle. BTW, how do I fake in-addr.arpa responses for NAT'd
space? My Oracle 8i server keeps checking the reverse addr every time I try
to create a DB. It's really annoying. Funny thing, my DB2 servers do the
same thing ...

Basing security on IP addresses on the other hand is while
not a complete
security solution, MUCH MORE SOUND than IN-ADDR. You can at least build
ACLs in your router(s) that don't allow spoofed traffic to enter your
network.

Then, why bother with DNS? This becomes a real problem with non-portable IP
blocks. My point remains, names are more portable than IP addrs.

Now, about the SSL security thing. SSL
certification is designed
to certify the identity of the server and that identity is
based on the
FQDN. SSL CERTs are around for the PRECISE reason that it is
too easy to spoof IN-ADDR, etc.

I agree, and always have, that reverse is easy to spoof. However, breaking
reverse is guaranteed to make some things fail. Some of those things are
proprietary code, owned by someone else, that I don't have sources for (and
which I paid a lot of money for). No, I don't have any clout with Oracle
(any more than you do, with Bill Gates).

> This is right on up there with:
>
> 1) You idiot DSL monkey, you deserve your Inet death
because you didn't
> multi-home.
> 2) No, you can't advertise less than a /20.
> 3) No, you don't deserve larger than a /32.
> 4) Yes, we know that makes multi-homing impossible for
those that need it
> the most.
> 5) No, we don't care, you idiot DSL monkeys deserve Inet death.
>
> Yeah, the message you send out is real clear.
> ... and one wonders why the Internet has an implosion problem...

And that's right up there with "<plonk!> me please! I'm an idiot DSL
monkey! WAAAAAAAAAA! My DSL provider went tits-up and I
hadn't built any
contengency plan. I'm going to go bankrupt! WAAAAAAAAA!"

I'm glad you enjoyed that, it was supposed to be funny. BTW, DSLnetworks is
still in business...how (if they're so bad)? But, that wasn't the point. The
point is that many of us, on the end-points, are being hung out there
without recourse. How do we multi-home to different providers when routing
gets munged as a guaranteed side-effect?

If your business depends (depended) on stable and reliable internet
connectivity with your own (or at least non-changing) address
space, might
I suggest that you should have gone to ARIN for a microblock
of address
space and established a contengency plan with some other
provider(s) in
the event that the sky fell?

I've been trying to do that for years. Minor technical difficulties keep
getting in the way, like routability. I can get the /24, already have the
ASN, but can't get it routed. If it's so easy, how come you haven't done it
yet?

I have. A long time ago.

EnterZone, Inc (ASN-ASN-ENTERZONE)
   6227 Headley Road
   Gahanna, OH 43230
   US

   Autonomous System Name: ASN-ENTERZONE
   Autonomous System Number: 13944

   Coordinator:
      Fraizer, John (JF1998-ARIN) John.Fraizer@ENTERZONE.NET
      +1 614 554-4356 (FAX) +1 614 228-5245

   Record last updated on 06-Nov-2000.
   Database last updated on 12-May-2001 22:47:54 EDT.

EnterZone, Inc. (NETBLK-ENTERZONE-CBLK-1)
   6227 Headley Road
   Gahanna, OH 43230
   US

   Netname: ENTERZONE-CBLK-1
   Netblock: 66.35.64.0 - 66.35.95.255
   Maintainer: NTZN

   Coordinator:
      Fraizer, John (JF1998-ARIN) John.Fraizer@ENTERZONE.NET
      +1 614 554-4356 (FAX) +1 614 228-5245

   Domain System inverse mapping provided by:

   NS1.ENTERZONE.NET 66.35.65.5
   NS2.ENTERZONE.NET 66.35.66.5

   ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE

   Record last updated on 13-Nov-2000.
   Database last updated on 12-May-2001 22:47:54 EDT.

route-server.exodus.net>sh ip bgp 66.35.64.0/19
BGP routing table entry for 66.35.64.0/19, version 11222293
Paths: (7 available, best #6)
  Not advertised to any peer
  701 6259 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.116 from 209.1.220.116 (209.1.220.116)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate
  701 6259 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.144 from 209.1.220.144 (209.1.220.144)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate
  701 6259 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.174 from 209.1.220.174 (209.1.220.174)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate
  6259 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.104 from 209.1.220.104 (209.1.220.104)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate
  6259 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.134 from 209.1.220.134 (209.1.220.134)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate
  6259 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.95 from 209.1.220.95 (209.1.220.95)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate, best
  5696 13706 13944, (aggregated by 13944 66.35.64.1)
    209.1.220.193 from 209.1.220.193 (209.1.220.193)
      Origin IGP, localpref 1000, valid, internal, atomic-aggregate

I find it funny that PostgreSQL - while being used as replacement for
Oracle by more and more people - does _not_ have this problem... I didn't
even have a NIC in the server when I installed it...

(And yes, PostgreSQL does have ACL's - but the ACL list is checked at
connection time - not everytime you execute a DML statement.)

-- snip --
# By default, allow anything over UNIX domain sockets, localhost and a few
# other machines.
local all trust
host all 127.0.0.1 255.255.255.255 trust
host all 10.20.10.249 255.255.255.255 trust
host all 10.20.12.194 255.255.255.255 trust
host all 0.0.0.0 0.0.0.0 password