Hi Nick, All,
Thanks for the links. I'm glad to know people are working on this. I don't
think anyone was suggesting that this was a new phenomenon.
Someone wrote to this list about a particular incident and I shared details
about how this was part of a larger IP squatting operation. Unique fr
Hi Doug, All,
We’ve seen similar things, including hijacks of less specific IP prefixes (even
/8s), correlated with spam behavior.
We presented on this at NANOG 35:
http://nanog.org/meetings/nanog36/presentations/feamster.pdf
Slide 4 shows a short-lived BGP announcement for IP space that was
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 1
.-- 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 "som
On Wed, Sep 3, 2014 at 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
> discussion on Nanog recently."
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 expertis
On Tue, Sep 2, 2014 at 12:08 PM, Job Snijders 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 wrote:
>>
>> > What is the real damage of hijacking a prefix which is not in use?
>>
>> 'not in use' ... where?
>>
>> What if
On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
> On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders 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
> 'interna
On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders 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 attempting to hijack
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 sc
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 cr
>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 advert
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 192
>> 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,
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 a
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 wrote:
> Would it not help if RIPE un-publishes these ASN's
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 wrote:
> On Sun, Aug 31, 2014 at 12:47 PM
On Sun, Aug 31, 2014 at 12:47 PM, Doug Madory 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
> you receive route
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
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 descri
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 wrote:
>
>
> Matthew Kaufman writes:
>
>> I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
>> regi
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
> alrea
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 been added to someone's spam source list. When I see that,
On Fri, Aug 29, 2014 at 06:39:07PM -0400, Robert E. Seastrom wrote:
>
> Matthew Kaufman 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 sure you ha
Matthew Kaufman 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
apologies. that was meant to be private. sigh.
randy
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 wrote:
>
>
>See "whois -r AS43239".
>
>The long term solution is to deploy RPKI and only use
>transits which use R
On Friday, August 29, 2014, Randy Bush 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 real work
On 8/29/14, 9:08 AM, "Randy Bush" 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 horse race to
>> 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?
consideri
> 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
On 8/28/14, 11:28 PM, "Mark Andrews" 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 to roll
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 do
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, prefe
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
On Aug 29, 2014, at 6:08 AM, Job Snijders 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 the
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 (l
> 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
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 le
>>> 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
cl
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) against
> From: Saku Ytti
> 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 is why
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
> 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 (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
spec
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
, Tarun Dua writes:
> AS Number 43239
> AS Name SPETSEN
In this case.. Google that ASN name. Then go upstream.
On 29-Aug-2014 8:56 am, "Faisal Imtiaz" wrote:
> 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 & Tele
On Aug 28, 2014, at 9:55 AM, Tarun Dua 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.
>
> http://bgp.he.net/AS43239#_prefixe
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
- Original Message -
> From: "Tarun Dua"
> To: nanog@nanog.org
> Sent: Thursday, August 28, 2014 12:55:25
49 matches
Mail list logo
