[arin-ppml] BGP Hijacking Definition

Larry Ash lar at mwtcorp.net
Mon May 6 19:00:31 EDT 2019


> 
>> 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

Larry Ash
Mountain West Technologies
123 W 1st St.
Casper, WY 82601
Office 307 233-8387



More information about the ARIN-PPML mailing list