FW: FW: We disagree with recent restrictions on ip allocationaimed at attacking the "littlehosts"

Hi All,

I know I am venturing into a minefield here...especially since this has
started to take on a rather condescending tone on both main sides of
this issue.  However, I thought I could give some more constructive
points to this argument, and let others provide good ideas to counter my
concerns with ARIN's policy re: virtual web hosting.  Please, if you
consider my points some sort of attempt to add to the "noise" on this
topic, then just ignore it totally.  Also, please try to hold back on
claiming inexperience on my part...accusing others of this is just a
totally unfounded conjecture, and requires a lot more information to be
presented than anyone's comments on this topic to this list will
convey.  Come on folks, let's give each other a break, and presume that
some of us actually know some of what we are talking about...and turn
our sour comments into helpful suggestions, and keep open minds.  After
all, we are ALL affected by ARIN's policies, and there is still much
room for some of us to find real-world problems with this particular
one.

That being said, know this: I have seen all of the comments on this
thread from this list, and others from other folks I have spoken with
and lists devoted to this topic, and read all of ARIN's docs on the
matter, and read quite a lot about this entire issue in the press and
from other sources.  Not to mention running my own ISP and web hosting
facility for the last 6 years, being heavily involved with the Internet
in a research capacity since its map fit on one sheet of paper, and
working with many other technical folks at other much larger ISPs...you
get the point.  Enough about me...

Brief re-cap of pertinent issues related to this policy (edited by me,
of course :-):

* IPv6 will *not* fix this for any of us now.  And, when it comes, it'll
hurt at first, but be better later.  No help here for now.
* Host-header (HTTP 1.1) virtual hosting is useful ONLY for web traffic
(HTTP, that is).  On the surface, good way to reduce IP needs, but maybe
not...
* FTP and any other protocols (telnet, heaven forbid...) might need
similar mechanisms depending on the way hosters have organized their
offering, and some exist for some, although not transparently at this
point.
* SSL web sites really need separate IPs, or at least it seems so. 
Different common names might be enough, but browsers may get confused. 
Seems fixable, but who really knows...perhaps Microsoft will "fix" it in
IE, and claim once again that they brought you the Internet, and now do
it even better than everyone else...:-)
* Here's a big one, which we should all really just accept: IPv4 space
is just too small, and it *will* run out if we are not creative in our
thinking...

Now for some of the "non-issues", just to make sure we can be fair
(IMHO, of course :-):

* Older browsers and cachers that do not grok HTTP 1.1 are just not that
common anymore.  This used to be on my hot list, but I ran the numbers
myself for a bunch of really big sites, and I had to shutup on this one
after the first real look.
* Folks who block IPs via "nanny" services or router ACLs or firewall
rules will not always have better tools at their disposal to make this
Host-header sensitive...remember that a lot of these mechanisms are
costly, and replacing them is not merely a technical issue.  But, if a
way around the issue could be made simple, and not require application
protocol-level packet filtering (as Host-header-based blocking would
require), then folks with more primitive filters would at least have a
way to do what they need...I think this is a non-issue because I have an
idea that may help here...if my idea does not help, than I will agree
that this is a real issue to be concerned about, at least for now.
* Big ISPs won't benefit over smaller ones in any way that day-to-day
technicians will deal with, since using Host-header virtual hosting is
really easy in just about every web server worth using (oops...a bit too
much opinion there? :-).  And this is coming from someone who sees
himself as a relatively small hoster.

Whew.  Probably already offended someone, or got someone hopping mad
that I did not list their concerns, or bespoke one that they think is
off-base...c'est la vie.  I am trying to help, so try to bear with
me...here's where I go where I fear you'll have reason to flog me, so
don't waste your energy just yet...

I, personally, worry about the following things re: this policy, and I
do not think I have seen these in this thread yet...if so, sorry in
advance:

* Packing a bunch of virtual web sites into a single web server instance
via Host-header parsing is all well and good, but what about complex
sites that use scripting modules or other application services within
the address space of the web server?  Imagine this (which I can, since
it happens way too often): You have 10 sites in an instance, all virtual
via Host-header, using a mix of PHP, embedded Perl, SSJS or SSI, etc. 
Now, someone (most likely your client) deposits some code which either
elicits a bug in the app module, or drops your server into a nasty loop,
or some such...and in the end, it ties up the entire web server
instance, causing quite a DOS situation.  As a businessman, does this
represent a risk I am willing to bear?  My answer is no...any others out
there?
* I know that our hosting offering concentrates a bit more heavily on
security-related matters, and every time you try to virtualize a
service, you can list the risks associated with it and enumerate the
methods of attack/compromise just the mere act of virtualizing opens you
to.  Now, I do not think for a moment that our final solutions are
un-hackable, but we do try to avoid the obvious ones, and some of the
no-so-obvious ones...and a lot of that comes from separating things to
as low a level as possible.  This goes beyond trusting a web server to
have little-to-no security holes; this is about taking preventive steps
to try and avoid an architecture that even allows the chance of a
compromise.  So, with that as a backdrop for further consideration, see
this in your mind: not only do those 10 web sites all share the same OS
instance and filesystems, but they also share the same memory and
address space, the same ability to control program execution, and the
same ability to access other services within your network that grant
credential-based access.  Anyone from the security realm want to take a
crack at this one?  And if anyone goes down the chroot() path, know
this: it helps a great deal, but is nowhere near perfect.  I'll stay out
of it...I promise...except to say that this is another business risk I
cannot accept, without dumping security from my list of "must-haves" in
my offering.
* As for the issues related to multi-homing and route redundancy and
such, the trend is obviously about consolidation...put your systems in a
facility that is closer to the backbone with many peering arrangements,
and part of a larger group of IP-needy companies, and you'll get what
you need from the network maintainer.  You won't get six 9's uptime, and
you won't get immediate technical support when you need it at all times,
and you will still need to justify your IP needs.  But, you'll fix some
of that by providing your own layer of customer and technical support to
cover your needs, finding the right folks within the network
maintainer's organization to help you when the chips are down, and by
shopping around for the folks who are big enough and also provide (and
then prove demonstrably) their own redundancies and fault-tolerant
architectures.  But, then again, there's that last one: justifying your
IP needs.  These big network facilities will force you to basically do
their ARIN-homework for them, with the same restrictions...so, this
policy will affect you even in the consolidated case.  In other words,
numbers convey no extra strength in this regard.

Before anyone gets the idea that I see some sort of way out of all of
this without a great deal of work and acceptance on the part of many
folks, know this: I don't.  But, I wonder about the following two ideas,
and would love to hear others help me refine them into something which
will help all of us a great deal.  Or, so I hope...

* When you get right down to it, the real technical reason why we can't
run separate instances of a web server and still use Host-header virtual
hosting is because OSes do not allow us to have separate processes
listen on the same IP/Port pair and de-multiplex based upon
application-protocol information.  You can rig up something close (as
Apache does), but it turns out to be a load-balancing mechanism, not a
separation thing; separate threads or processes can kinda "share"
incoming connection load, but in the end, any of the members of the
"farm" need to be able to handle any of the requests.  As an ex-kernel
hacker myself, I can see the plethora of problems with allowing
something more "intelligent", and the time it would take to shake out
all of the bugs in it, even after you figure out the right rules to
apply to have it all "make sense" in the end.  If threads in these OSes
really gave us proper separation, both at the execution level and the
credentials level, then things would be somewhat better, but you'd still
have a main thread issue; something has to make the first
de-multiplexing decision, based on some piece of information, and when
it isn't IP and Port anymore, it's gotta be something in the protocol
(Host-header, for instance), and hence a user-level process
responsibility.  I have reached my ability (for now :-) to give this
further development, but can anyone else help?
* This really gets in my craw: what about port numbers?  With all of the
services out there, we still use relatively few port numbers on our web
servers.  When I load balance one of my client's web presences, I don't
even bother with IPs...I just spread things out over port numbers. 
Works like a charm, and is easy as pie.  Why not use this in virtual
hosting as well?  We'd get all of the separation we need, since the OS
restrictions would vanish, and we'd be able to embrace a reduction in IP
needs without sacrificing stability or security (in any more way than
running a web server at all does :-).  Again, I ask, why not?  I'll
answer it: because we have stuck ourselves on port 80 for HTTP, and have
pursued no way of opening up that restriction to our advantage.  All
because our URL names need to be easy to remember, short to type, and we
can't trust the end-user with numbers.  All of which I agree with.  Even
if we allowed for symbolic port names via a naming system, it'd probably
cause too much trouble (imagine these: foo.com:joe, microsoft.com:visio
(shame), etc.).  But, what if we gave DNS some more work to do, and
browsers a bit more intelligence.  How about allowing protocol-specific
DNS records that you can associate with DNS hosts (like the INFO
records), that can contain some info pertinent to the protocol or its
layers.  Imagine a DNS zone for foo.com having an A record of 1.2.3.4
and a HTTP_INFO (?) record of 2035, and one for bar.com having an A
record of 1.2.3.4 and an HTTP_INFO record of 2036.  Now, when a browser
gets foo.com in an HTTP URL, it can do the DNS lookup, and use both the
A record *and* the HTTP_INFO record (if it exists, otherwise default to
80) to access the site.  Browsers would take on a backward-compatible
change (the :port syntax would have to override the DNS info, just to be
clean), and DNS maintainers would have all of the control over the port
assignments, with little-to-no extra pain.  Then, we could go even
further by using this for other protocols...although I expect that
acceptance of this and prevalence of this behavior in client-side
software would take time.  After all, the whole "well-known" port number
thing is a vestige of a time when folks needed port numbers and were
trusted with remembering them...something we have moved away from, and
with good reason.  I have to say that this one intrigues me the
most...we'd no longer need Host-headers at all, and it would provide a
platform for solving similar issues for protocols other than HTTP.  No
changes to any existing protocol, a minor extension to DNS (which has
mechanisms already for this), and a simple application-level behavioral
change to the browsers of the world.  SSL sites will work with different
ports (browsers use port number as well as IP in distinguishing sites
and authentication realms), and folks who want to block access could
simply add a port number to their block (which even very primitive
mechanisms support with little extra work).  Would someone please take a
factual approach to dowsing this with water if it has something really
wrong with it?  With this in place, I'd start using it tomorrow...

Basically, in the end (if you even got this far :-), without creative
ways out like the ones above and others I am sure are out there, ARIN's
policy is just too heavy to take...too many things can suffer from it,
both relatively easy to accept and damaging to accept.  But, if we are
not careful, we'll just run out of IPv4, and stare out the window one
day like deer caught in the headlights.  Can we get any help from those
strident, creative folks who bring us things like DNS and HTTP and Linux
to help us come out of this one with something good?  Can someone with
more clout than my name registers add their voice to this line of
inquiry, so the entire Internet space can benefit from some creative
thinking?  Can the folks at ARIN, who I know want to help this community
survive and help us all just "get along" with one another, help us apply
the pressure needed to get ideas like these worked out?  I try in my own
way, but if ARIN wants folks to be happy when being forced to accept
their policies, than it would be the least they could do (I think) to
help us solve the "real" problem and not just their specific one
(running out of IPv4).  Opinions?

Tom Palmieri
CTO & Co-founder
Quadrix Solutions

Rich Fulton wrote:
> 
> On Fri, 4 Aug 2000, AveHost.com Staff wrote:
> 
> > Without backing up a statement like that I can only assume you cannot.
> 
> Actually the statement was right on.  I would recommend you stop making
> assumptions and start participating in policy discussion while seeking
> IP, routing, and general Internet enlightenment.
> 
> > -----Original Message-----
> > From: Sweeting, John [mailto:John.Sweeting at cwusa.com]
> > Sent: Thursday, August 03, 2000 8:53 PM
> > To: 'info at avehost.com'; Rich Fulton
> > Cc: Policy at Arin. Net
> > Subject: RE: FW: We disagree with recent restrictions on ip allocation
> > aimed at attacking the "littlehosts"
> >
> >
> > I strongly recommend that you become an active member of ARIN and
> > participate in the meetings; then you would understand that most of your
> > assumptions are way off the mark.
> >
> > -----Original Message-----
> > From: AveHost.com Staff [mailto:ceo at REGSEARCH.COM]
> > Sent: Thursday, August 03, 2000 12:47 PM
> > To: Rich Fulton
> > Cc: Policy at Arin. Net
> > Subject: RE: FW: We disagree with recent restrictions on ip allocation
> > aimed at attacking the "littlehosts"
> >
> >
> >
> > OK, I apologize if I have perhaps been too vague.  My assumption is that
> > more IP's are available to upstream providers and many of them are now large
> > web hosting providers (e.g., C&W, AT&T, Bellatlantic, SW Bell, Sprint, etc).
> > Those upstream providers have not wanted to use IP's for web hosting for a
> > long time due to "more important", perhaps justified, uses for them in
> > Network functions and other services (e.g., network/POP build-outs, and
> > redundant networks, DSL services, downstream services, etc).  Thus, why
> > would they not be for the restriction of IP assignment for the smaller,
> > downstream web hosts where more IP's are available for their Data Center,
> > POP, DSL service, massive build-outs?
> >
> > In the end, the consumer is the one that suffers from more exposure to DNS
> > problems, problems with changing  providers (and the "churn" rate is high
> > from large providers because they are really, really, at least most of them,
> > about providing excellent customer service to customers), etc.  How does the
> > customer suffer in changing providers in the IP-less web hosting scheme?  It
> > is not as seamless anymore, because the customer lacks a dedicated ip
> > address to publish their existing content to before DNS propagation
> > completes for the domain nameserver changes.  I realize there are ways to
> > "rig" things to make it possible for the customer to publish content from
> > their existing site but it still depends on host headers which are not fully
> > compatible with all systems, namely, older browsers, some proxy and firewall
> > systems, and, how do you deal with providing SSL in the IP-less environment?
> >
> > One thing the larger hosts would love to do is eliminate (which won't
> > happen) or slow it down, thus why not make it harder to leave, or at least
> > more painful?
> >
> > AveHost.com Staff
> >
> >
> > -----Original Message-----
> > From: rich at farnsworth.nullroute.net
> > [mailto:rich at farnsworth.nullroute.net]On Behalf Of Rich Fulton
> > Sent: Thursday, August 03, 2000 11:57 AM
> > To: info at avehost.com
> > Cc: Policy at Arin. Net
> > Subject: Re: FW: We disagree with recent restrictions on ip allocation
> > aimedat attacking the "littlehosts"
> >
> >
> > "expand the numbering system" is hardy a trivial task.  a "better routing
> > scheme" is not necessarily dependent on ip space.
> >
> > i still fail to see how a smaller web hosting company is treated unfairly
> > by ARIN policy.
> >
> > On Thu, 3 Aug 2000, AveHost.com Staff wrote:
> >
> > > I agree that this discussion is not amounting to anything, but the idea
> > that
> > > we have to treat IPv4 as a commodity rather than as a useful tool is that
> > > not the "proverbial tail wagging the dog"?  Call it naivety on my part,
> > but
> > > why not just expand the numbering system and have 15 numbers, or even 18
> > > numbers rather than 12 and we'll have a lot more time to develop an even
> > > better routing scheme before we run out of IP's.
> > >
> > > AveHost.com Staff
> > >
> > > -----Original Message-----
> > > From: Len Rose [mailto:len at netsys.com]
> > > Sent: Thursday, August 03, 2000 11:25 AM
> > > To: info at avehost.com
> > > Cc: policy at arin.net
> > > Subject: Re: We disagree with recent restrictions on ip allocation aimed
> > > at attacking the "littlehosts"
> > >
> > >
> > > Dear AveHost.com Staff:
> > >
> > > The internet is constantly evolving. In order to remain on
> > > the internet, we all have to evolve.
> > >
> > > It's an unfortunate byproduct of that evolution that the
> > > threshold or "bar" gets raised every 6 months or so.
> > >
> > > Whether or not that unfairly impacts smaller operations
> > > is more of a technical issue and somewhat less of a
> > > financial issue.
> > >
> > > I used to be a rabid "virtual webhosting based on IP is best"
> > > kind of person when I was wearing a systems-oriented hat,
> > > but if you examine same from a networking viewpoint you
> > > should consider it evil to waste so much IP address space
> > > on $9.95 web sites.
> > >
> > > (yes, I made a gross stereotype)
> > >
> > > If your business model is dependent on ip-based hosting
> > > then you need to raise some more capital and buy someone
> > > who owns a few /16's.
> > >
> > > The real question will be how things evolve after IPv4
> > > ceases to be a barrier.
> > >
> > > Just my opinion or whatever you see fit to call it! I
> > > strongly debated about even copying this to policy@
> > > but this thread looks like it's turning into a non-useful
> > > ping pong match.
> > >
> > > Len
> > >
> > > On Thu, Aug 03, 2000 at 11:16:25AM -0400, AveHost.com Staff wrote:
> > >
> > > > Once again, because the smaller hosts don't have all the technology
> > needed
> > > > to route the way the larger hosts do, I stated this previously.  It is
> > > quite
> > > > obvious that this is an unfair advantage to the larger hosts.
> > > >
> > > > AveHost.com Staff
> > >
> > >
> > > [trimmed]
> > >
> > >
> >
> >
> >
> >
> >
> >   /rf
> >
> >
> 
>   /rf

-- 
Thomas Palmieri
Quadrix Solutions