:25 PM
Subject: Prefix hijacking, how to prevent and fix currently
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
Hi,
Matthew Petach wrote:
Be aware that even if you don't think you're peering with them
directly, you may be picking up routes via the public route
servers at exchange points, so check to see if you need to apply
filters on your route server peerings as well.
At the risk of receiving
squatting for spam generation. Pierre and I have since compared
notes on this topic.
-Doug Madory
- Original Message -
From: Tarun Dua li...@tarundua.net
To: nanog@nanog.org
Sent: Thursday, August 28, 2014 12:55:25 PM
Subject: Prefix hijacking, how to prevent and fix currently
http://www.bgpmon.net/using-bgp-data-to-find-spammers/
This blog post furthers this discussion, but it would have been appropriate to
cite my original analysis explicitly, rather than simply citing some
discussion on Nanog recently.
If we want to foster a community where people share expertise
On Wed, Sep 3, 2014 at 10:27 AM, Doug Madory dmad...@renesys.com wrote:
http://www.bgpmon.net/using-bgp-data-to-find-spammers/
This blog post furthers this discussion, but it would have been appropriate
to cite my original analysis explicitly, rather than simply citing some
discussion on
.-- My secret spy satellite informs me that at 2014-09-03 10:27 AM Doug
Madory wrote:
http://www.bgpmon.net/using-bgp-data-to-find-spammers/
This blog post furthers this discussion, but it would have been appropriate
to cite my original analysis explicitly, rather than simply citing some
On (2014-09-01 21:34 +), Sriram, Kotikalapudi wrote:
Hi Sriram,
Please help me understand the argument.
Some Org. D can maliciously announce a subprefix under Org. C's prefix,
and get away with it due to the 'Loose' mode.
So C is advertising valid 192.0.2.0/24
Is D advertising valid
Please help me understand the argument.
Some Org. D can maliciously announce a subprefix under Org. C's
prefix, and get away with it due to the 'Loose' mode.
So C is advertising valid 192.0.2.0/24
Is D advertising valid 192.0.2.0/23?
This is unfixable problem? If D is advertising
On Tue, Sep 02, 2014 at 03:08:28PM +, Sriram, Kotikalapudi wrote:
The example that I gave was not that. In my example, C has legitimate
ownership of the less specific (e.g., 192.0.2.0/23). D is malicious
and attempting to hijack a subprefix (e.g., 192.0.2.0/24).
Importantly, C has a
On (2014-09-02 14:44 +), Sriram, Kotikalapudi wrote:
Hi Sriram,
Importantly, C has a created a ROA for 192.0.2.0/23 only to protect
its address space, but currently *does not advertise* this prefix or any part
of it.
So D's more specific announcement (hijack) is 'Invalid' in this
On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders j...@instituut.net wrote:
On Tue, Sep 02, 2014 at 03:08:28PM +, Sriram, Kotikalapudi wrote:
The example that I gave was not that. In my example, C has legitimate
ownership of the less specific (e.g., 192.0.2.0/23). D is malicious
and
On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders j...@instituut.net wrote:
What is the real damage of hijacking a prefix which is not in use?
'not in use' ... where?
What if the 'owner' of the block has the block only routed
On Tue, Sep 2, 2014 at 12:08 PM, Job Snijders j...@instituut.net wrote:
On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders j...@instituut.net wrote:
What is the real damage of hijacking a prefix which is not in use?
'not in use'
Would it not help if RIPE un-publishes these ASN's from their whois database ?
I filed the abuse report at RIPE but haven't heard back from them. We
are NOT a RIPE member but an APNIC member.
Regards
-Tarun
On Mon, Sep 1, 2014 at 3:49 AM, Matthew Petach mpet...@netflight.com wrote:
On Sun, Aug
Hi Tarun
Not really. People who are filtering route are filtering already since only
you have route object for it and people who are not filtering, for them
RIPE DB and whois won't matter.
On Mon, Sep 1, 2014 at 2:58 PM, Tarun Dua li...@tarundua.net wrote:
Would it not help if RIPE
On (2014-09-01 14:58 +0530), Tarun Dua wrote:
Hi,
Would it not help if RIPE un-publishes these ASN's from their whois database ?
I filed the abuse report at RIPE but haven't heard back from them. We
are NOT a RIPE member but an APNIC member.
Not sure against what RIPE rule it would be and
Loose mode RPKI:
- verified or unknown less-specific route is preferable to failing
more-specific
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
Subject: Prefix hijacking, how to prevent and fix currently
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
On (2014-08-31 14:04 -0400), Doug Madory wrote:
Hi,
FWIW, this is from an IP squatting operation I came across in recent weeks. I
encounter these things regularly in the course of working with BGP data -
probably others do too. Usually I look up the ASN or prefix and often it has
already
You're funny. What percentage of legacy holders have or will sign the LRSA do
you suppose?
Matthew Kaufman
(Sent from my iPhone)
On Aug 29, 2014, at 3:39 PM, Rob Seastrom r...@seastrom.com wrote:
Matthew Kaufman matt...@matthew.at writes:
I look forward to the ARIN fee schedule for
Ah yes BusinessTorg (AS60937). I have also seen this one doing what you are
describing. Not to MSFT or GOOG, but another major technology company that we
peer with. In fact, it is going on right now but only visible if you receive
routes directly from them. A while ago, I sent them a note
On 29/08/2014 23:39, Rob Seastrom wrote:
I'd assume that it would be included in your annual LRSA maintenance
fees.
it will be interesting to see if we get proposals in the future to move
legacy space between RIRs.
Nick
On Sun, Aug 31, 2014 at 12:47 PM, Doug Madory dmad...@renesys.com wrote:
Ah yes BusinessTorg (AS60937). I have also seen this one doing what you
are describing. Not to MSFT or GOOG, but another major technology company
that we peer with. In fact, it is going on right now but only visible if
On (2014-08-29 03:24 +), Fred Baker (fred) wrote:
Do you implement RPKI? Are providers that neighbor with them implementing
RPKI?
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
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
On Fri, Aug 29, 2014 at 06:25:16PM +0900, Randy Bush wrote:
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?
The proposed 'loose' mode protects against unauthorized hole punching
From: Saku Ytti s...@ytti.fi
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.
+10
And it would completely remove false-positive blackholing.
This
Am 29.08.2014 11:25, schrieb Randy Bush:
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
No, as the the more specific route is signed and is preferred (longest
match routing)
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 29.08.2014 11:39, schrieb Randy Bush:
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
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
On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
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
On Aug 29, 2014, at 6:08 AM, Job Snijders j...@instituut.net wrote:
On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
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
On Fri, Aug 29, 2014 at 06:17:09AM -0400, Sandra Murphy wrote:
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.
On (2014-08-29 18:39 +0900), Randy Bush wrote:
clearly i am missing something. got a write-up?
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,
On (2014-08-29 14:37 +0300), Saku Ytti wrote:
clearly i am missing something. got a write-up?
Loose mode RPKI:
- verified or unknown less-specific route is preferable to failing
more-specific
Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest
match is not done to
On 8/28/14, 11:28 PM, Mark Andrews ma...@isc.org wrote:
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
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
On 8/29/14, 9:08 AM, Randy Bush ra...@psg.com wrote:
considering that measured rpki registration (which has a very tragic
side) is ten time ipv6 penetration, i think we ask for rpki first.
WG] I guess I should know better than to ask rhetorical questions on
NANOG, lest I get an answer.
The
On Friday, August 29, 2014, Randy Bush ra...@psg.com wrote:
i am ENOTIME. when you have a simple spec i can follow, i would really
look forward to it.
Thanks for summing up in a few words how most of us outside your ivory
tower feel about RPKI.
Now if you'll excuse me, I'm a grown-up with
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
registrations.
Matthew Kaufman
(Sent from my iPhone)
On Aug 28, 2014, at 8:28 PM, Mark Andrews ma...@isc.org wrote:
See whois -r AS43239.
The long term solution is to deploy RPKI and only use
transits which
apologies. that was meant to be private. sigh.
randy
Matthew Kaufman matt...@matthew.at writes:
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
registrations.
I'd assume that it would be included in your annual LRSA maintenance
fees.
-r
On Fri, Aug 29, 2014 at 06:39:07PM -0400, Robert E. Seastrom wrote:
Matthew Kaufman matt...@matthew.at writes:
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
registrations.
I'd assume that it would be included in your annual LRSA maintenance
fees.
Make
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
, 2014 12:55:25 PM
Subject: Prefix hijacking, how to prevent and fix currently
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
On Aug 28, 2014, at 9:55 AM, Tarun Dua li...@tarundua.net wrote:
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.
Internet Telecom
- Original Message -
From: Tarun Dua li...@tarundua.net
To: nanog@nanog.org
Sent: Thursday, August 28, 2014 12:55:25 PM
Subject: Prefix hijacking, how to prevent and fix currently
AS Number 43239
AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started
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
In message
50 matches
Mail list logo
