IP-Hosting Policy Specifics

[Susan Zeigler]

The post I sent earlier today didn't seem to go through so I'm posting it again,
apologies if anyone receives this twice:

Several months ago, I wrote and FAQ and posted information regarding SSL and
host-header based hosting. Following is an exerpt from that:

In order for a certificate to work on more than one site, 2 of three
things need to be different: domain, port, or IP.

If you are maintaining multiple web sites on one certificate, it can
easily be done using only one IP. There must always be one IP per
certificate, however, so if you are running multiple certificates on the
same server you will need more than one IP assigned to that server--one 
for each certificate.

The certificate should be registered with a designated host-name under
your primary domain. (example: secure.webhostersmaindomain.com)
This will point to the root site of your server if you are running IIS 4
or anywhere on IIS 5 and other web hosting applications.

This is the directory you will set up SSL for and where all of the
actual home directories of the sites that will be accessed via SSL. You
then set up the virtual site and any time you want to access via SSL
site, you set up a redirect to the the URL
<secure.webhostersmaindomain.com/mydirectory> where
<mydirectory> is the name of the home directory. In addition, creating
the sites as an application under that root site can help to easily
designate them.

The only exposure this scheme has is with identity. If someone would
click on the lock, it will list the secure.webhostersmaindomain.com as
the owner, however this issue is the same for anyone who is running
multiple sites off the same certificate, so it doesn't come into play
with regards to the IP scheme. The only way to combat this argument is
to then have multiple certificates, with each individual client owning
their own. This is costly, however, so many web hosting companies don't
do this.

The web-hosting clients that I have don't get any complaints with this
method. In fact, their clients love it because they don't have to buy
their own certificate.




Alberto Mujica wrote:
> 
> Since technical reasons can be pretty specific I agree with the fact that
> there should be a list of technical reasons to justify IP address
> allocations and an escalation procedure to suggest new ones.
> 
> My main concern, would providing SSL to our customers be a sufficient
> technical justification?
> In theory, SSL can be provided with host names, but Windows 2000 and NT for
> example allow binding of a certificate to only one IP Address.
> 
> Thanks,
> 
> Alberto Mujica
> Database Administrator
> MCDBA, MCSE, MCP+I, A+
> albertm at innerhost.com
> 
> -----Original Message-----
> From: Jim Macknik [mailto:jmacknik at inflow.com]
> Sent: Thursday, May 03, 2001 8:11 AM
> To: 'vwp at arin.net'
> Subject: IP-Hosting Policy Specifics
> 
> I really think we need ARIN to really lay down what "technical
> justifications" there are for requesting IP space for IP-based hosting. This
> request has appeared many times on this discussion list, but the only answer
> I have seen to date indicates that ARIN requires "technical justification;"
> this is a little too vague for businesses that depend on IP space, and the
> customers which they support.
> 
> Is there a definitive list of justifiable reasoning behind IP-based hosting.
> If there is not, then there is no way that anyone offering any IP space to
> their customers could be sure they are requesting the right information from
> their customers. This could conceivably cause them to lose their ability to
> do business if ARIN indicates they don't believe that organization is
> providing proper justification.
> 
> Is there any way we can come up with a list of justifiable reasons to use
> IP-based hosting? If so, can we then also come up with an escalation
> procedure for requesting additions to the list as technology and standard
> practices change? If we had these in place, then companies offering ISP
> services could follow, to the letter, exactly what ARIN needs for them to be
> compliant. They would also have an opportunity to argue a case for alternate
> technical reasons for IP space.
> 
> -= Mack =-
> 
> James M. Macknik
> Manager, Systems Engineering
> 2401 15th St. Suite 200
> Denver, CO  80202
> 303/824.2506 (Office)
> 720/840.5329 (Mobile)
> jmacknik at inflow.com

-- 

-- 
-Susan
-- 
Susan Zeigler            |      Technical Services
szeigler at spindustry.com  |      Spindustry Systems
515.225.0920             |