Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

[hostmaster]

Each of the webserver instances are leased to others. They are in control 
of the Apache configuration on their individual Apache instance, and 
nearly all of them have multiple websites on them, run by the person 
leasing the server.  Under the DMCA, the person leasing is responsible for 
the DMCA complaints and if I receive one from someone that chooses to 
ignore the SWIP record and sends it to me (1st upstream), I simply forward 
it back to the customer for processing.  In any case I know of no way to 
have multiple instances of Apache (one controlled by each customer) 
running on the same machine without each instance being bound to its own 
IP address.

As to CALEA, you are NOT allowed to tell the customer that they are being 
monitored.  Thus, even if Apache allowed the monitoring to take place, you 
could not use that feature since changing the Apache config of a customer 
to permit it would be the same as telling them you are doing it. 
Besides, they might overwrite any changes you made with their next update 
if they maintain and edit local copies of these files on their computer 
and simply upload updates as needed or use other version control tools 
that would flag changes.  Apache is also not the only thing you must 
monitor with a CALEA Order.  You must provide ALL communication to and 
from the customer, including things like SMTP, FTP, POP3 and even SSH. 
Effectively, it is the same as an sniffer on the IP address of the 
ethernet, and in fact tcpdump is the tool we use here to capture the 
communications from their assigned IP after instructing the switch to 
allow it to be dumped to a monitoring machine.  As you point out in your 
posting it is the *transmission* function that is subject to CALEA. 
While you are not required to hand over emails and the like that are 
stored on the machine, any files transmitted over the connection to the 
internet are fair game, including email if they choose to download it 
across the internet connection in the clear. The CALEA order is directed 
to the internet connection of the person named in the order, and not the 
machine itself. One big loophole to CALEA being effective in this case is 
that if the machine encrypts the transmissions being sent to/from the 
internet, you are only required to provide the actual transmission of data 
to/from the internet, which is encrypted.  Same with SSH, Https and the 
secure versions of Imap and Pop3. In todays world, they are not getting 
very much in the clear.

While I understand that you would like to see all hosting done with the 
use of the fewest possible IPv4 address use to conserve it for the longest 
period of time.  However ARIN policy does not require this.

I do think that IPv4 will not be the primary protocol of the internet in 
10 years. IPv6 will win the battle in the long run. Most of the top 1000 
web sites already have it, and many of the access providers already 
provide it. Google is already at 25%. Ironically, due to the differences 
in SWIP for IPv4 and IPv6, it is required to give each IPv6 customer a 
full /64 in order to register their contact information in SWIP, while 
current rules for IPv4 allow (but do not require) SWIP registration all 
the way down to a /32.

Mobile app stores have moved to a IPv6 requirement. Even Facebook has said 
they moved most of their network to IPv6 to avoid CGNAT for a better and 
faster customer experence for those customers with IPv6 addresses.  They 
even reported that IPv6 can be faster than IPv4 based on their 
measurements.

ARIN tried to get the world's operators to get on board routing networks 
smaller than a /24 but had no luck.  Therefore asking ARIN to assign 
networks smaller than a /24 is a non starter.

I know that hosting can cram thousands of hosting accounts onto just one 
IP address.  The problem here is it is hundreds of wholesale hosting 
accounts each controled individually, each account hosting hundreds of 
domains.  That is a bit harder to operate on a single IP. We do give each 
wholesale customer their own IPv4 and IPv6 address as they request.

This discussion has drifted very far from choosing a /22 maximum, a /24 
maximum or other items in the Draft Proposal or its reasonable amendments 
would suggest. As previously discussed, it is really about if a /22 would 
have less abuse than the current policy.  Or a /23 or /24 as you suggested 
to make the wait list maximum as low as a /24.

The current ARIN assignment guidelines would have no problem with my 1 per 
customer IPv4 assignment as this is the "normal" standard worldwide. 
Since you believe everything should run under a single IP, I am guessing 
you will never have to go to ARIN for space, since you can clearly get 
that single IP from whoever your access provider is.  ARIN policy does not 
permit smaller than a /24. (4.2.1.5)

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Sun, 3 Mar 2019, Ronald F. Guilmette wrote:


In message <Pine.LNX.4.64.1903030119350.26017@localhost.localdomain>,
hostmas...@uneedus.com wrote:

Strictly speaking, the laws talked about do not REQUIRE each customer have
his/her own IP address, but from a practical point of view, giving each
customer his/her own IP address is the easiest way to comply with these
laws.

Examples include CALEA, which starts at 42 USC 1002.  This law requires
certain parties including internet access providers to provide under court
order the content of communications upon service of a Court Order.
Effectively, this is a wiretap.  Without each customer connection having
its own unique address, it is nearly impossible to comply with this law. A
wiretap order can be obtained against a website, and the law requires the
communication operator to deliver to the government JUST the communication
of the subject of the order.  In the case of shared hosting, without a
unique identifer such as an IP address, it would be very difficult to
comply with the order and redirect a copy of their communications to the
government that does not contain the communications of all your customers.

I believe that I have understood you, but I also believe that it sounds
like utter lunacy to me that nobody working on, say, Apache, has yet
devised a solution for that seemingly simple (individual web site
"wiretap") problem that would work in the case of shared hosting.

It doesn't sound on the face of it like a terrifically hard problem.

I guess that somebody should ask the Apache folks about that.  I guess
that will be me, since it appers that nobody who is actually in the
hosting business has yet bothered to do so.

The other well known example is the DMCA. which is at 17 USC 512 et seq.
It requires disabling or taking down content that someone swears is
violating their copyright, or the operator becomes responsible for the
infringement.

Yeabut they can't just come to you and say "Please immediately take
down SOMETHING" and not adeuqately specify what they mean, specifically,
by "SOMETHING".  They've got to give you a URL, and that URL has to begin
with a domain name, so you can just remove that one domain name from your
Apache config and be done with it.  What's the problem?

If all the websites are hosted by a single server instance on the same
machine, of course this can be easily done by the operator by simply
knowing the URL of the content.  However, not all shared hosting happens
that way.  Those with high demand content might be hosted on a dedicated
server that is leased to another party.

Great!  So then if you get a DMCA for that, then you just shut off power
to that one server.  Problem solved, no?

For less demanding content, an
instance of the webserver running on a shared server might instead be
used.  In any case, each person leasing a server or webserver instance
controls completely what websites they choose to support.  If the IP is
shared as suggested, all the DMCA notices are going to be directed to the
owner of the server, who will not without engaging in a logging operation
know which instance (and therefore which customer) is hosting the
offending content.

You're talking in circles.  You have a DMCA complaint.  It specifies
a URL.  You are in the professional hosting business and yet you're
seriously telling me that you can't for the life of you figure out
how to shut off -just- that one revelant domain name without burning
all sorts of other and unrelated stuff to the ground?

Please do excuse my incredulity.

By keeping each customer on his/her own IP address,
the owner will know which customer is responsible since the report will
contain the IP.

So your claim is that its actually legally impossible to do shared hosting,
using Apache, anywhere in these United States, because if anyone tries
to do that, they will have to burn their whole shop to the ground in order
to eliminate that one pesky infringer who only owns one single domain name?

While this is the not the most efficient use of address space...

That's got to be the understatement of the millenia.

You've just asserted that even though Apache can host a few million web
sites all on one IPv4 address, the dumbasses who write the laws in this
country have cereated these requirements -and- that neither you nor anybody
else in the hosting businsess has managed to figure out how to satisfy
those requirements without unpacking each and every individual web site
onto its own unique IP address.  (And of course these all have to be IPv4
addresses, specifically.  IPv6 addresses just won't do, because otherwise
90% of the planet still won't be able to see the content.)

I can't help being facinated by these assertions because I could have
sworn that I saw, in some of the passive DNS data that I was looking at,
really quite recently, evidence indicating that at least -some- hosting
companies right here in the good old U.S. of A. *are* in fact packing
in their web hosting clients, like sardines, thousands at a time, onto
-single- shared IPv4 addresses.  But now you inform me that they can't
possibly do that without violating feredal law.  So I guess it must
all have been a big halicunation on my part.  Sorry.  My mistake.

Well, anyway, this all is still beating around the bush.  I give you a /24
and you *can* still host 256 separate customers on that, right?  For all
those that only need to run clients, you give them IPv6 instead. Only
the ones who really need to run their own servers, you give each of those
persons or organizations -one- IPv4 address to do it on.  If one organization
needs to have fifteen different corporate web sites, then fine.  They can
do that all from that one IPv4 address, and much much more, as needed.

The other thing I disagree with is your suggestion that clients should be
on IPv6 and servers on IPv4.  In fact, without the use of translation
technology, the two protocols cannot directly talk to each other.

Yes.  And?

Are you telling me that no such translators have been deployed already,
even here in 2019?

And isn't there a nice simple one-to-one mapping of each and every IPv4
address to its counterpart in the IPv6 space, so that translating from
IPv6 down to IPv4 and/or back again is actually rather straightfoward
and highly efficient, if not to say trivial?


Regards,
rfg

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.