Search Engines/IP restrictions/policy changes

[Ted Pavlic]

> > My argument now is that changing to name-based and suggesting
> > webhosting providers use technology which has expired in IETF DRAFT
> > form is not appropriate because the technology just isn't ready.
> I'm not sure exactly what you are referring to, but RFC 2068 in section
> 5.1.2 certainly seems to describe the method of sending the hostname with
> the GET request.  RFC 2068 is on a standards track.  Am I missing
> something?

I'm speaking specifically about SSL and TLS. HTTP/1.1 supports name-based
hosting, of course. However it is not currently very possible to support
name-based secure hosting.

ARIN gave these references with respect to secure webhosting:

http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-https-03.txt

http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-http-upgrade-05.txt

http://info.internet.isi.edu/in-notes/rfc/files/rfc2246.txt

Two of those are EXPIRED IETF **DRAFTS** which should never be used for
reference. Those particular drafts suggest a way for name-based hosting to
exchange the name-based information BEFORE the TLS handshake and then switch
to TLS once the host has been established.

The nature of SSL causes it to exchange certificates BEFORE any host
informatoin is sent. Because of this, in order to provide SSL webhosts a
hosting provider has to use IP-based web hosting.

>From what I know, there is currently no standard for exchanging host
information before a TLS or SSL handshake. These standards need to be in
place and then implemented in web browsers as well as servers in order for
name-base hosting to expand onto secure sites.

> > I just have to argue that the "web" is made up of much more than just
> > HTTP. My "web" consists of HTTP, HTTPS, FTP, and all of the
> > enhancements to each one of those (like FrontPage and the various
> > schemes which help make web servers run more smoothly).
> So perhaps we have a semantic problem here.  To me, the term "webhosting"
> in ARIN's policy means plain HTTP, hot HTTPS, FTP, or anything else, but I
> do see your point.  I would suggest re-wording the policy to say HTTP
> hosting.

I agree -- because that does seem to be what ARIN means.

> > Already policy routing exists, but I think that even policy routing
> > needs to be able to look closer at a packet to decide exactly what kind
> > of packet it is. I don't think that processing the current information
> > being passed on the Internet could be done fast enough to provide
> > efficient name-based load balancing/etc.
> Well, part of the problem is that the information needed isn't, and really
> can't be, neatly contained in a single packet, you have to capture the
> first x packets in a session to capture things like URL and whatnot, which
> means doing some TCP spoofing, however the technology is there and is
> getting better by the minute.

That's why I think that there needs to be some abstraction layer between the
actual services that name-base hosting affects and TCP. An easy way for web
servers, FTP servers, load balancers, etc. to see exactly where the traffic
is going. Unfortunately, without sending bytes and bytes and bytes of
variable length information, it's almost as if we need another set of IPs on
top of IP. <sigh> Send one IP with a four-byte OIP (Other-IP) which looks up
on some server somewhere and ends up resolving the 20-byte name. :)

Recently someone suggested to me that perhaps the SYN which starts a
connection which usually carries no data could carry data -- the name of the
host to which the end-user is connecting. Web browsers would somehow have to
be able to tell their TCP stack to send this information with the SYN... The
receiving server could then parse this information.

The technology is there -- it just needs to be put together.

> > Once a user's DHCP lease is up, they release their IP and ask for a new
> > one. Usually at that time they get the same IP back. That's just one of
> > the fun things about DHCP.
> I'm well aware of how DHCP works.  The point that I was trying to make is
> that, at least the last time I looked, there was a 1 to 1 ratio of IPs to
> cable customers, thereby guaranteeing that they would always get the same
> address.

I didn't mean to sound like I was talking down to you; I apologize if it
seemed like I was.

Considering a great deal of cable subscribers stay on-line 24/7 or
close-to-it, I think it would be difficult for providers to keep a less than
1 to 1 ratio of IPs to customers. That's why I thought that handing out
10./8 or 172.16./16 (or both!) using the existing DHCP would be a decent
idea. The only thing the cable providers would have to worry about is the
latency doing the NAT, and that could be taken care of a number of ways.
People who wanted static IPs could easily be setup with one-to-one NAT. Just
like when dial-up ISPs were told to use dynamic addresses, this sort of
conversion involves EXISTING technology... and I don't really think would
require that much effort to convert.

Note that the local DSL providers in my area actually provide STATIC IPs to
their customers, from what I remember. I have to wonder if that's within the
current regulations.

> I do think the savings available by using host based webhosting is
> significant, but I'm pointing out that some flavor of dynamically
> addressing cable modems would provide even more savings.

Still -- remember that in ARIN's policy changes not only are they forcing
webhosting providers to move to name-based hosting, but they are expanding
the largest block an ISP (like @Home) can allocate at one time from /14 to
/13. To me it looks like they're taking the IPs (even though they probably
can't free up THAT many from webhosting, IMO) from webhosting providers and
giving them to cable ISPs.

> > I should hope issues like these are brought up in October.
> I'm sure they will be.  Better yet, go to the meeting and make sure they
> are.

I'm just a lowly young college student -- not sure my schedule will allow
it. I just hope that there's someone out there who feels similar to me who
will be going who bring these issues up.

All the best --
Ted