Larry Ash wrote :
Does ARIN or any of the other RIR's really want to get into these kind
of network engineering and operations debates?
For the record, I have said that I agreed that prop-266 was out of scope. But some people have asked pertinent questions and
clarifications.
Fair enough. I just feel we are wandering into a swamp.
I would argue that if a host and the server that provides service to that host
are within the same ASN then the network and it's traffic is private.
I have to disagree with that. Let me give you an example : I am at home, and I am accessing the web site of my city for whatever
reason.
The traffic stays between the same ASN because we happen to have the same ISP, but this is not private traffic. The boundary
between private and public is at the interface between the ISP and the customer / subscriber. For me, the Internet starts between
my router and the aDSL modem of my ISP.
In your example I agree however the website is likely at a remote hosting
company. I have had city/county request
connections that were clearly intended to be private and not available
publicly. If that connection had
public traffic on it I never knew nor did I have the right to know.
I was thinking of a more limited case where frequently RFC1918 space has been
used in the past.
Also, I have had to deal with a few organizations that insist (rightly I might
add) that they control all
RFC1918 addressing that touches them. A bit of a corner case though.
There are systems and services that are so sensitive or compromise so costly
that it is imperative
that no contact from outside the local ASN be allowed. It becomes a form of
Russian roulette to put
a world routable address on them. So we have had to come up with an
alternative. Many have resorted
to 30.0.0.0/8 in the voice community since the attacks on voice resources are
so heavy and persistent
that a ddos can result from trying to use packet filters to protect some
systems.
Please note that I am not judging. I wrote recently that this prop-266 would scare the wrong people, those who do unsavory
things because they don't have an alternative. Some think you should roast in the flames of hell for eternity, not me.
Do you (or the organizations you help) sell voice services to the public that are hosted on these systems that have a 30/8
address ?
Yes, if what you mean by public is directly connected customers. It is on
mostly proprietary equipment but always
running inside vlans that are used for voice only or as tunnel addresses when
connecting incompatible RFC1918 networks
together. If the customers equipment is compromised thousands of toll calls can
be placed in a single evening
to innocent third parties with the familiar "Microsoft calling about a virus on your
computer" type of phone spam.
Michel's definition also has grey areas when it comes to ip-ip tunnels. If
tunnel
traffic has what we all would call public traffic is the tunnel itself public?
A tough one.
If it's your own VPN tunnel, it's private. If an ISP sells you an MPLS tunnel,
I'd say it public.
I tend to say that something a providers sells to a third party is public,
unless it comes down to dark fiber or wavelength.
As I said, it is a bit grey depending on specific details. I would argue that
if you can treat it as a layer two connection
no matter how the provider implements it, it's essentially private.
It seems to me that any clean definition suffers from the problem of too many
implementations some of which are totally outside
of the norm.
Larry
Michel.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
Larry Ash
Mountain West Technologies
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
