ARIN Web Hosting Policy

[Bryan Heitman]

I think Stacey Son said it best with "There are many practical issues
that ARIN may have overlooked in drafting this policy"

We recently had to deal with this policy on a new allocation that we
received a few weeks ago.  At that time we drafted about a 3 page
explanation as to why IP based hosting is needed.  Many of the points in
that document have already been stated by all of you in support of IP based
hosting so I won't get into that.

Our belief is that Name-based hosting should be used only when technically
possible, however as most of everyone's platforms out there already rely on
IP based hosting, ARIN should not deny the request for allocation.  Doing so
would have significant negative effects.

Best,


Bryan Heitman, Vice-President
CommuniTech.Net, Inc. - (800) WEB-HOST


----- Original Message -----
From: "Stacey D. Son" <sson at veriohosting.com>
To: <ppml at arin.net>
Sent: Tuesday, August 29, 2000 4:15 PM
Subject: Re: ARIN Web Hosting Policy


> ARIN said:
> >Some individuals have expressed their disagreement with this new policy.
> >Should the ARIN web hosting policy be changed?
> >
> >ARIN would like your feedback on this issue.  Please post your comments
> >and suggestions to the public policy mailing list (ppml at arin.net). Your
> >feedback will be included in the discussions at the upcoming public
> >policy meeting.
>
> In http://www.arin.net/announcements/policy_changes.html ARIN
> announced that "[they] will not accept IP-based webhosting as
> justification for an allocation".  There are many practical issues
> that ARIN may have overlooked in drafting this policy.  Name-based
> hosting has a number of implementation issues including:
>
> (1) Lack of support in SSL/TLS.  Because the SSL/TLS session is
> created before HTTP is allowed to pass in current implementation any
> data it requires an unique IP address for dedicated certificates.  If
> a shared certificate is used browers will report a possible security
> violation back to the user on the client side which makes it difficult
> to complete an on-line ecomerce transaction in most cases.  While the
> IETF draft "Upgrading to TLS Within HTTP/1.1" (see
> http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-http-upgrade-05.txt)
> proposes a solution to this problem this idea is still far from being
> implemented.  Once it is implemented it may take years before a
> significant percent of the users upgrade their browsers.  (The
> adoption of HTTP/1.1 support in browsers took years to reach 90%, for
> example).
>
> (2) Denial of Service (DoS) attacks on web servers have a much larger
> scope.  Given the current state of IP it is possible for someone (even
> anonymously) to generate a DoS attack on a web server.  Within the
> last few years distributed DoS (DDoS) attacks have appeared and their
> effects have been made public (see
> http://staff.washington.edu/dittrich/misc/ddos/).  These attacks
> generated enough traffic to the point were large Internet sites' web
> servers could not response to respond to valid requests.  There are
> lots of proposals to the DDoS problem but, in short, nothing really
> has been deployed or proven to work.
>
> In a shared web hosting environment a DoS attack can take down more
> than the target web site since multiple web sites are hosted on the
> same web server.  This may take down hundreds or thousands of web
> sites in addition to the target web site.
>
> With IP-based web hosting the target web site that is under attack by
> a DoS can quickly be identified and dealt with.  One common method of
> reducing the effects of the DoS attack is to add a host route to null
> at the broader routers.  This way the router drops the traffic
> generated by DoS attack to the targeted site and the other web sites
> hosted on the same server will operate as normal while network
> engineers attempt to trace the source of the attack.  Since name-based
> all the web sites share the same IP address a DoS attack the null
> routing method will take down all the hosted sites and not just the
> target site.  In addition, it is much more difficult to identify the
> target of the attack since it can be any of the sites sharing the same
> IP address.
>
> This same problem can be applied generally to things like filter
> services.  If one IP address gets blocked for some reason or another
> all the name-based web sites are blocked.
>
> (3) Current bandwidth shaping methods will not work.  Most, if not
> all, web hosting companies use a kernel-based or switch-based
> bandwidth shaping.  In order for this to work each web site must have
> its own IP address.
>
> (4) Performance issues in web server software.  Popular web servers
> such as apache implement hashing on IP-based virtual hosts but not on
> name based hosts.  Name based hosts are looked up by a linear search.
> This could have a significant impact on various web hosting business
> models since hosting density may need to be changed.
>
> (5) Lack of support in other protocols.  HTTP is only one aspect of
> web hosting.  Most, if not all, web hosting companies also offer POP3,
> SMTP, FTP, etc.  None of these protocols have support for name-based
> virtual hosting and rely on the fact an unique IP address is used.
> While it would be possible to require the domain name in the
> authenication stage of the protocol many hosting companies have
> developed large amounts of software that is IP based.
>
> Verio Web Hosting feels that ARIN should rethink this policy and
> discussed it with representives of the web hosting community rather
> than just those who may not understand all the issues involved.  (BTW,
> I did not see a companion policy from ARIN requiring the deployment of
> NAT devices. ;)  I look forward to discussing this in person in October.
>
> Regards,
>
> -stacey.
>
> Stacey D. Son
> VP, Hosting Technology
> Verio Web Hosting
> "The World Leader in Web Hosting"
>
>
>