AS Number 43239
AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in
production, it worries us that it was this easy for someone to hijack
it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 <- This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd.
193.43.33.0/24 hydrocontrol S.C.R.L.
193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun
AS132420
I would say, start off with the NOC Contact
http://bgp.he.net/AS43239#_whois
It is most likely that someone has fat-fingered the IP space..
Faisal Imtiaz
Snappy Internet & Telecom
Do you implement RPKI? Are providers that neighbor with them implementing RPKI?
If not, complain to the folks not indicating RPKI and therefore accepting a hijacked prefix. Including yourself.
In this case.. Google that ASN name. Then go upstream.
See "whois -r AS43239".
The long term solution is to deploy RPKI and only use
transits which use RPKI. No RPKI support => no business.
Additionally make RPKI a peering requirement.
Mark
I feel RPKI would be much more marketable if vendors would implement 'loose'
mode.
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
This mode would protect from routed hijacks, but not from non-routed hijacks,
which are less serious. And it would completely remove false-positive
blackholing.
There is very small incentive for SP to deploy RPKI, since user-error in
far-end, would make my product look worse than competitors product. I'm
spending money to lose money.
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
randy
The proposed 'loose' mode protects against unauthorized hole punching
No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.isn't that exactly the hole punching attack?
No, as the the more specific route is signed and is preferred (longest
match routing) against the less specific hijacked route
clearly i am missing something. got a write-up?
randy
sorry my mistake, you're right
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.isn't that exactly the hole punching attack?
No, as the the more specific route is signed and is preferred (longest
match routing) against the less specific hijacked routeclearly i am missing something. got a write-up?
sorry my mistake, you're right
been around this a few times. no magic pill found. would love to learn
of one. but one either wants to stop mis-originations or not.
but i would like to see an actual write-up of this 'loose mode' and
terse would be fine, heck preferred. 
randy
I'll attempt to clarify.
Assume:
ROA: 10.0.0.0/16, max_length = 16, origin = AS123
in RIB: 10.0.0.0/16 origin AS123 (valid)
With the above two conditions any updates containing more-specifics
of 10.0.0.0/16 would be rejected/not-installed, just like in todays
'strict mode'
Loose mode A would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the
loose mode would kick in and one could accept more specifics for
10.0.0.0/16, but only when originated by AS123.
Loose mode B would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the
loose mode would kick in and one could accept more specifics for
10.0.0.0/16 originated by any ASN.
The major point is that when the valid route is missing, one might
choose to accept invalid routes. When the valid route returns, the
invalids are purged from your table.
Or in other words: Proposal is, that when additional 'loose' mode is
configured, invalid routes are accepted if and only if they are the only
route to destination. If there is any other route (less-specific) which
is not invalid, it will be used, instead of the invalid route.
Kind regards,
Job
In your examples, you presume there's a ROA for the less-specific.
Here you say "not invalid", which would mean a route that is "unknown", i.e. no ROA exists.
Your Loose Mode A relies on the existence of the ROA - you accept more specifics but only when originated by the ASN in the ROA.
So which do you mean? The less specific has a ROA or the less specific may not have a ROA?
(Just trying to work this out in my head.)
--Sandy
P.S. All the RPKI use is subject to local routing policy, so working out impact of different policies is a really good thing.
> Loose mode A would look like this:
>
> In the case that 10.0.0.0/16 origin AS123 is not in your table, the
> loose mode would kick in and one could accept more specifics for
> 10.0.0.0/16, but only when originated by AS123.
>
> Loose mode B would look like this:
>
> In the case that 10.0.0.0/16 origin AS123 is not in your table, the
> loose mode would kick in and one could accept more specifics for
> 10.0.0.0/16 originated by any ASN.
>
> The major point is that when the valid route is missing, one might
> choose to accept invalid routes. When the valid route returns, the
> invalids are purged from your table.
>
> Or in other words: Proposal is, that when additional 'loose' mode is
> configured, invalid routes are accepted if and only if they are the only
> route to destination. If there is any other route (less-specific) which
> is not invalid, it will be used, instead of the invalid route.In your examples, you presume there's a ROA for the less-specific.
Correct.
Here you say "not invalid", which would mean a route that is
"unknown", i.e. no ROA exists.
Sorry, with "not invalid" i meant "valid".
Your Loose Mode A relies on the existence of the ROA - you accept more
specifics but only when originated by the ASN in the ROA.
I'd like to accept more-specifics, only in the absense of the
less-specific ROA covered prefix.
So which do you mean? The less specific has a ROA or the less
specific may not have a ROA?
The less specific has to have a ROA, for any loose mode to make sense.
Loose mode A & B came into existence 15 minutes ago, its good to discuss
what a loose mode could mean. 
Kind regards,
Job
Job got to it, but shortly:
Loose mode RPKI:
- verified or unknown less-specific route is preferable to failing more-specific
The main goal is always to have all routes, never to blackhole, prefering bad
route over no route.
Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest
match is not done to whole population, population is first divided to
'verified', 'unknown' and 'failed' routes, and longest match is done for each
sub-population in order, until match is found.
The long term solution is to deploy RPKI and only use
transits which use RPKI. No RPKI support => no business.
Additionally make RPKI a peering requirement.
WG] So should we ask for that before, or after we get everyone to roll out
IPv6 everywhere by voting with our wallets?
*ducks*
Are providers that neighbor with them implementing RPKI?
If not, complain to the folks not indicating RPKI and therefore accepting
a hijacked prefix.
WG]
%s/RPKI/inbound route filtering on downstream customers/g
There, FTFY
Tarun, other than directly contacting the originator, I recommend that you
complain to their upstream provider(s) (the neighboring ASN(s) in the
AS-Path) that they are accepting routes from their customer that they
shouldn't be, include proof that you own the block they are announcing,
and ask them to apply a prefix filter. Yes, this presupposes that you can
find valid contact info in whois or peeringdb, but it's the best we've got
right now.
RPKI isn't likely to fix this anytime soon, because it's mostly not
deployed where it needs to be to affect this problem. And just like
inbound route filtering and lots of other protective security measures,
[1, 2] and eating your vegetables, and getting more exercise, most folks
agree that it would help, but it's only useful with wide deployment, which
mostly needs to happen on "everyone else's network", and those things all
have an additional cost (time, money, or both) to deploy and maintain. The
unfortunate thing is that RPKI arguably takes more work than the others,
with a much longer time-horizon to see benefit during the incremental
deployment period.
Wes George
[1] https://www.routingmanifesto.org/manifesto/
[2] http://tools.ietf.org/html/draft-ietf-opsec-bgp-security
Anything below this line has been added by my company’s mail server, I
have no control over it.
Loose mode A & B came into existence 15 minutes ago, its good to
discuss what a loose mode could mean.
i am ENOTIME. when you have a simple spec i can follow, i would really
look forward to it.
randy
The long term solution is to deploy RPKI and only use
transits which use RPKI. No RPKI support => no business.
Additionally make RPKI a peering requirement.WG] So should we ask for that before, or after we get everyone to roll
out IPv6 everywhere by voting with our wallets?
considering that measured rpki registration (which has a very tragic
side) is ten time ipv6 penetration, i think we ask for rpki first.
but keep shoveling. it's a good week for twt.
randy