Re: attribution

[Sandra Murphy]

I’m using CAIDA’s bgpreader and this one looks like it might be an example of 
what you want.

R|R|1586714402.00|routeviews|route-views.eqix|||2914|206.126.236.12|103.148.41.0/24|206.126.236.12|2914
 58717 134371 134371 134371 134371 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 
140076 140076 140076 140076 140076 140076 140076 140076 140076|140076|2914:410 
2914:1405 2914:2406 2914:3400||

—Sandy

> On Apr 13, 2020, at 3:17 PM, Randy Bush  wrote:
> 
> Apr 12 17:57:42 r0.iad rpd[1752]: Prefix Send failed ! 103.148.41.0/24 
> bgp_rt_trace_too_big_message:1209 path attribute too big. Cannot build update.
> 
> so some idiot is barfing out a ridiculous as_path.  dear lazynet, is
> there an easy way to get attribution for this stupidity?  i.e. the
> as_path.
> 
> e.g. a nice query to ris or rv given the prefix, 103.148.41.0/24, and
> the uct time, Apr 12 17:57:42.
> 
> randy

Re: Tell me about AS19111

[Sandra Murphy]

> On Feb 6, 2020, at 2:38 PM, b...@theworld.com wrote:
> 
> 
> It would likely be a lot better than "someone on NANOG noticed a
> discrepancy let's shout at each other about it for a few days."


Did I miss something?  I thought the discrepancy being pointed out was that 
resources that were not currently allocated/assigned were still being actively 
used and actively accepted by people who should have rejected them.  Private 
address space and private ASNs are one case, resources that have not yet been 
allocated or were once allocated and have been reclaimed are another.

An accounting audit of ARIN resource management process is not going to help 
the fact that people are accepting routes they should not be accepting.

I suspect I did miss something.

—Sandy

Re: User Unknown (WAS: really amazon?)

[Sandra Murphy]

Scott, you might want to read "Policy Development Process (PDP)” 
https://www.arin.net/participate/policy/pdp/ in order to discover just exactly 
what John means by “If the community developed a policy”. 

You might also want to join the Public Policy Mailing List, arin-p...@arin.net, 
to discuss.  Scintillating discourse, I assure you.

—Sandy




> On Jul 31, 2019, at 10:17 AM, Scott Christopher  wrote:
> 
> John Curran wrote: 
> 
>> Scott - 
>> 
>> Alas, you have a fundamental misunderstanding about the nature of ARIN…  we 
>> don’t do anything other than implement policies that this community wants.  
>> If the community developed a policy to require Abuse POC’s validation, and 
>> said policy made clear that failure to do so was to result in revocation, 
>> then ARIN would indeed implement the policy (and that includes revocation 
>> for those who ignored the policy.) 
> 
> Hello John - you are absolutely right. Since the community has shown 
> overwhelming disapproval of Amazon's invalid abuse POC, please go ahead and 
> revoke Amazon's resources.
> 
> Maybe do this late Friday afternoon for the courtesy toward Amazon's support 
> staff ?
> 
> And since this will certainly be historic, please post an announcement to 
> nanog-list ?
> 
> Thanks, and Good luck !
> 
> S.C.

Re: CloudFlare issues?

[Sandra Murphy]

Martijn - i3D.net is not in the list Job posted yesterday of RPKI ROV 
deployment.  Your message below hints that you may be using RPKI.  Are you 
doing ROV?  (You may be in the “hundreds of others” category.)

—Sandy

Begin forwarded message:

From: Job Snijders 
Subject: Re: CloudFlare issues?
Date: July 4, 2019 at 11:33:57 AM EDT
To: Francois Lecavalier 
Cc: "nanog@nanog.org" 

I believe at this point in time it is safe to accept valid and unknown
(combined with an IRR filter), and reject RPKI invalid BGP announcements
at your EBGP borders. Large examples of other organisations who already
are rejecting invalid announcements are AT, Nordunet, DE-CIX, YYCIX,
XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International,
and hundreds of others.



> On Jul 4, 2019, at 5:56 AM, i3D.net - Martijn Schmidt via NANOG 
>  wrote:
> 
> So that means it's time for everyone to migrate their ARIN resources to a 
> sane RIR that does allow normal access to and redistribution of its RPKI TAL? 
> ;-)
> 
> The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were 
> both major reasons for us to bring our ARIN IPv4 address space to RIPE. 
> Unfortunately we had to renumber our handful of IPv6 customers because ARIN 
> doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain.
> 
> Therefore, Cloudflare folks - when are you transferring your resources away 
> from ARIN? :D
> 
> Best regards,
> Martijn
> 
> On 7/4/19 11:46 AM, Mark Tinka wrote:
>> I finally thought about this after I got off my beer high :-).
>> 
>> Some of our customers complained about losing access to Cloudflare's 
>> resources during the Verizon debacle. Since we are doing ROV and dropping 
>> Invalids, this should not have happened, given most of Cloudflare's IPv4 and 
>> IPv6 routes are ROA'd.
>> 
>> However, since we are not using the ARIN TAL (for known reasons), this 
>> explains why this also broke for us.
>> 
>> Back to beer now :-)...
>> 
>> Mark.
> 

Re: Spamming of NANOG list members

[Sandra Murphy]

So sheer coincidence.  Literally.

—Sandy

> On May 23, 2019, at 7:07 PM, Niels Bakker  wrote:
> 
> * sa...@tislabs.com (Sandra Murphy) [Fri 24 May 2019, 00:28 CEST]:
>> And it arrived oddly coincident with my visit to the cvent registration 
>> page.  Any others who had that coincidence?
> 
> No, and I've gotten like five by now.
> 
> 
>   -- Niels.

Re: Spamming of NANOG list members

[Sandra Murphy]

Mine came 21 May.  It was a .doc.  

Sent from charter.net, with the user portion of the sender very similar to a 
nanog contributor.

And it arrived oddly coincident with my visit to the cvent registration page.  
Any others who had that coincidence?

—Sandy


> On May 23, 2019, at 5:39 PM, Richard  wrote:
> 
> On 5/23/19 4:16 PM, Matt Harris wrote:
>> On Thu, May 23, 2019 at 4:13 PM Hansen, Christoffer 
>>  wrote:
>> Appreciate the warning!
>> 
>> On 23/05/2019 19:46, Valerie Wittkop wrote:
>> > These messages are not flowing through NANOG servers, nor using the NANOG 
>> > domain. They are not messages coming from the NANOG organization. Please 
>> > be aware if you receive a message matching this description and always 
>> > make sure to scan attachments for a virus.
>> 
>> The one I received looked like this:
>> 
>> > From: "NANOG" 
>> 
>> ...
>> 
>> Has it been considered switching to "-all", instead of only "~all" in
>> the spf record?
>> 
>> > $ dig +short +nocmd +nocomments TXT nanog.org
>> > "v=spf1 include:_spf.google.com ip4:104.20.199.50 ip4:104.20.198.50  
>> > ip4:50.31.151.75 ip4:50.31.151.76 ip6:2001:1838:2001:8::19 
>> > ip6:2001:1838:2001:8::20 ip6:2400:cb00:2048:1::6814:c632 
>> > ip6:2400:cb00:2048:1::6814:c732 ~all"
>> 
>> -Christoffer
>> 
>> The SPF record wouldn't make a difference since that email was sent from 
>> @cegips.pl, not from @nanog.org.  You'd have to change the SPF record for 
>> the cegips.pl domain to impact their ability to send from that address.  
>> 
> The one I received was from rainphil.com and came with an ugly Trojan 
> attached as a PDF. 
> 
> Has anyone else received this type or am I just fortunate?
> 
> Richard Golodner
> 
> 
> 
> 

Re: question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT

[Sandra Murphy]

I’d like to express my appreciation for the fact that PCH makes the data 
available and has for many years.

The data collected by RouteViews, RIS and PCH is a god-send for researchers and 
operators alike.

—Sandy

> On Oct 2, 2018, at 5:57 AM, Bill Woodcock  wrote:
> 
>>> On Oct 1, 2018, at 2:04 PM, Sandra Murphy  wrote:
>>> 
>>> DHS had a program called PREDICT that made information important for 
>>> security research available.
>>> 
>>> The follow on is called IMPACT.  https://www.impactcybertrust.org
>>> 
>>> The key note speaker said his data was available under PREDICT, perhaps he 
>>> meant IMPACT.  Internet Atlas does show up on the IMPACT site.
>>> 
>>> The IMPACT program has announced (see their home page) that due to a lack 
>>> of funding support, the IMPACT program would cease operation in Dec 2018.  
>>> That “continued use of existing data will expire and your ability to 
>>> request data through IMPACT will no longer exist”.
>>> 
>>> Can someone ask the speaker (can’t find support for remote attendees) if he 
>>> knows if any impact from IMPACT’s ceasing to operation on the ability to 
>>> look at the data that he said was available through PREDICT?
> 
> All of the PCH data will continue to be available directly from us, despite 
> the PREDICT/IMPACT portal going away.
> 
>-Bill
> 

Re: question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT

[Sandra Murphy]

Thank you thank you thank you for the person who saw my question and relayed at 
the mike!

—Sandy


> On Oct 1, 2018, at 2:04 PM, Sandra Murphy  wrote:
> 
> DHS had a program called PREDICT that made information important for security 
> research available.
> 
> The follow on is called IMPACT.  https://www.impactcybertrust.org
> 
> The key note speaker said his data was available under PREDICT, perhaps he 
> meant IMPACT.  Internet Atlas does show up on the IMPACT site.
> 
> The IMPACT program has announced (see their home page) that due to a lack of 
> funding support, the IMPACT program would cease operation in Dec 2018.  That 
> “continued use of existing data will expire and your ability to request data 
> through IMPACT will no longer exist”.
> 
> Can someone ask the speaker (can’t find support for remote attendees) if he 
> knows if any impact from IMPACT’s ceasing to operation on the ability to look 
> at the data that he said was available through PREDICT?
> 
> —Sandy Murphy, Parsons

question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT

[Sandra Murphy]

DHS had a program called PREDICT that made information important for security 
research available.

The follow on is called IMPACT.  https://www.impactcybertrust.org

The key note speaker said his data was available under PREDICT, perhaps he 
meant IMPACT.  Internet Atlas does show up on the IMPACT site.

The IMPACT program has announced (see their home page) that due to a lack of 
funding support, the IMPACT program would cease operation in Dec 2018.  That 
“continued use of existing data will expire and your ability to request data 
through IMPACT will no longer exist”.

Can someone ask the speaker (can’t find support for remote attendees) if he 
knows if any impact from IMPACT’s ceasing to operation on the ability to look 
at the data that he said was available through PREDICT?

—Sandy Murphy, Parsons

Re: videos from NANOG73?

[Sandra Murphy]

Apologies.  I fell victim to autocomplete.  I did not mean that query to go to 
the whole list.  I’ve forwarded appropriately.

—Sandy


> On Jul 5, 2018, at 11:11 AM, Sandra Murphy  wrote:
> 
> The agenda for NANOG73 is still on the cevent site.  The links for slides all 
> seem to be there, which is good.
> 
> But only the sessions on Monday morning have links for the videos.  
> 
> I hope that’s not due to a taping failure.
> 
> I looked in the archive, and the presentations from NANOG73 aren’t there.  
> Understandable.
> 
> It does look like they are available on youtube.
> 
> Can you let me know when the videos will be available on the nanog site?  I 
> like to point people to the nanog site, so they can get everything, past, 
> present and future, mail, videos, slides, etc, all together.
> 
> —Sandy
> 

videos from NANOG73?

[Sandra Murphy]

The agenda for NANOG73 is still on the cevent site.  The links for slides all 
seem to be there, which is good.

But only the sessions on Monday morning have links for the videos.  

I hope that’s not due to a taping failure.

I looked in the archive, and the presentations from NANOG73 aren’t there.  
Understandable.

It does look like they are available on youtube.

Can you let me know when the videos will be available on the nanog site?  I 
like to point people to the nanog site, so they can get everything, past, 
present and future, mail, videos, slides, etc, all together.

—Sandy

Fwd: [cooperation-wg] Massive IP blockings in Russia

[Sandra Murphy]

Of possible interest to this group.  

Forwarding at Alexander’s suggestion, who says he has already shared info in 
the NANOG facebook group "(with updated prefixlist)".

—Sandy

> Begin forwarded message:
> 
> From: Alexander Isavnin 
> Subject: [cooperation-wg] Massive IP blockings in Russia
> Date: April 17, 2018 at 1:36:33 PM EDT
> To: cooperation...@ripe.net
> 
> Dear colleagues!
> 
> I’m not pleased to inform you that RosComNadzor, a Russian Communication 
> supervisory body, has started blocking huge ranges of IPs belonging to 
> different cloud infrastructures, mostly Amazon and Google Cloud.
> Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15, 
> 18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13, 34.248.0.0/13, 
> 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15, 52.0.0.0/11, 52.192.0.0/11, 
> 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15, 54.144.0.0/12, 54.160.0.0/12, 
> 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16.
> 
> Russian ISPs MUST fully block all traffic to such networks. The list is 
> frequently updated and gets automatically propagated to ISP every once in a 
> while, failure to block any address may result in 1500eur fine.  
> The infrastructure listed above is being added to the blocklist under 
> “counter-terrorist and counter-extremist” order of the General Prosecutor 
> Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking an 
> arbitrary unwanted content.
> The real reason for such blocking is an attempt to cut access to Telegram 
> messenger, which refused to provide end-to-end encryption keys to the Federal 
> Security Service (previously known as KGB). This is a case similar to 
> San-Bernardino shooter’s, where the FBI was denied access to the shooter’s 
> iPhone, but courts in Russia have made completely opposite decision.
> Telegram’s infrastructure is being blocked by a different decision by 
> RosKomNadzor, #2-1779/2018.
> Cloud infrastructures are being blocked for massive proxy and VPN hosting 
> used to dodge messenger blocking.
> 
> It is said, that more Apple and Google networks may be blocked soon for apps 
> updates and push notifications delivery for Telegram.  
> 
> We hope to still have the global IP connectivity to keep you informed about 
> how the situation develops.
> Do not be surprised if some of your services placed in cloud infrastructures 
> will miss Russian customers.
> 
> You can monitor the number of IP addresses, domains and URLs to be blocked in 
> Russia at the https://2018.schors.spb.ru/ page (run by the famous ENOG 
> community member Phil Kulin).
> Detailed information (also via API) is available at the 
> https://reestr.rublacklist.net run by RosKomSvoboda civil society group.
> 
> Kind regards,
> Alexander Isavnin
> 
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: hijacking of 128.255.192.0/22

[Sandra Murphy]

You are pointing out that 138.255.192.0/22 is the likely cause of the hijack of 
128.255.192.0/22, right?

(No need to be privately told - that’s straight from the LACNIC Whois)

—Sandy

> On Mar 20, 2018, at 3:40 PM, Alejandro Acosta 
>  wrote:
> 
> Hello,
> 
>   Someone in Lacnog privately told me this:
> 
> 
> aut-num: AS263971 owner: FaleMais Comunicações LTDA responsible: Paulo
> Henrique Mem Pereira owner-c: LEVAL5 routing-c: LEVAL5 abuse-c: LEVAL5
> created: 20150831 changed: 20150831 inetnum: 138.255.192.0/22 inetnum:
> 2804:28a0::/32 inetnum: 170.254.76.0/22 
> Regards, Alejandro,
> 
> 
> El 20/3/18 a las 2:35 p. m., Jay Ford escribió:
>> Something apparently in Brazil is hijacking 128.255.192.0/22, part of
>> 128.255.0.0/16 which is held by the University of Iowa.  AS 263971 is
>> announcing 128.255.192.0/22 which Hurricane Electric is accepting &
>> propagating.  None of that has any authorization.
>> 
>> I can't find any decent contact information for the originating
>> entity, so I have reported it to ab...@he.net, but it'd be fabulous if
>> some HE folks listening here could whack the hijacking faster than the
>> abuse channels will get to it.  Also useful would be some functional
>> contact for AS263971.
>> 
>> Any help will be appreciated.
>> 
>> 
>> Jay Ford, Network Engineering Group, Information Technology Services
>> University of Iowa, Iowa City, IA 52242
>> email: jay-f...@uiowa.edu, phone: 319-335-

Re: BGP hijack: 64.68.207.0/24 from as133955

[Sandra Murphy]

Not to respond to my own post, or anything.  But.

Another interesting thing.

bgp.he.net reports show that AS133955 is/was also announcing 69.172.127.0/24  
"WiMore S.r.l.".  bgp.he.net shows a red key icon on that origination, meaning 
that there’s an RPKI ROA that does not match that origination.  And bgp.he.net 
reports an RADP route object with a proxy registration for AS133955 to 
originate 69.172.127.0/24, registered on 9/25 like the three prefixes below.  

RADB still reports that route object (along with a very old one)

route: 69.172.127.0/24
descr: Fleg Asia Telecom Ltd
Proxy-registered route object
origin: AS133955
notify: ipbb-a...@aptg.com.tw
mnt-by: MAINT-AS17709
changed: kiay...@aptg.com.tw 20170925 #00:31:36Z
source: RADB

route: 69.172.64.0/18
descr: Canaca-Com Inc
descr: 1650 Dundas Street East Unit 203
descr: Mississauga, Ontario
descr: CA
origin: AS33139
mnt-by: MNT-CANAC
changed: peer...@canaca.com 20100624
source: ARIN

stats.ripe.net shows 69.172.127.0/24 is presently being announced - "Originated 
by: AS133955 (valid route object in RADB)”, "100% visible (by 157 of 157 RIS 
full peers)"

The RPKI says that AS34526 (WiMore S.r.l.) is authorized to originate 
69.172.96.0/19.  But the aggregate prefix is not being announced.  If the 
AS133955 origination is valid, they really ought to update their ROA.

Hm. I am curious about that prefix.  Is it being hijacked?  Or am I just 
reading everything wrong?

—Sandy

> On Oct 4, 2017, at 1:45 PM, Sandra Murphy <sa...@tislabs.com> wrote:
> 
> 
>> On Oct 4, 2017, at 11:29 AM, Theodore Baschak <theod...@ciscodude.net> wrote:
>> 
>> I noticed when I looked into both of these leaks 3 hours after Clinton's
>> message yesterday that I couldn't see them in any of the looking glasses I
>> was looking in (including the NLNOG looking glass)
>> 
>> Looks like things were able to be cleaned up very quickly.
> 
> Interesting.
> 
> bgp.he.net is still reporting AS133955 as the originator of 64.68.207.0/24.  
> I don’t know what their refresh cycle is.
> 
> And, oh look, bgp.he.net points to an RADB proxy registration for the 
> AS133955 origination.  RADB no longer reports that route object.  But it must 
> have been there at some point.
> 
> RADB
> route:  64.68.207.0/24
> 
> descr:  Fleg Asia Telecom Ltd
>Proxy-registered route object
> origin: AS133955
> notify: ipbb-a...@aptg.com.tw
> mnt-by: MAINT-AS17709
> changed:kiay...@aptg.com.tw 20170830  #05:45:57Z
> source: RADB
> 
> stat.ripe.net (bless you, RIPE!) shows that 64.68.207.0/24 has been 
> originated by AS133955 off and on for the last month (since the RADB route 
> object’s change date?) in the BGP Update Activity and Routing History graphs. 
>  And a huge flurry of activity yesterday.
> 
> Could I be reading all this wrong?  Seems to have been going on for quite a 
> while.
> 
> —Sandy
> 
> P.S.  The other three prefixes mentioned below show similar results in 
> bgp.he.net, with route objects proxy registered on 9/25, and similar results 
> in stats.ripe.net, with off-and-on announcements, more off than on for these, 
> closely timed with the route object registration. 
> 
> 
>> 
>> 
>> 
>> Theodore Baschak - AS395089 - Hextet Systems
>> https://bgp.guru/ - https://hextet.net/
>> http://mbix.ca/ - http://mbnog.ca/
>> 
>> 
>> 
>> 
>> On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work <clin...@scripty.com> wrote:
>> 
>>> TELUS AS852 has three address blocks hijacked by AS133955 as well.   We
>>> have not been able to get in contact with AS24155.  It looks like they
>>> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505.
>>> 
>>> 68.182.255.0/24
>>> 74.49.255.0/24
>>> 96.1.255.0/24
>>> 
>>> 
>>> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote:
>>>> 
>>>> as133955 is broadcasting bogus BGP announcement for our netblock
>>>> 64.68.207.0/24
>>>> 
>>>> It's in China, and we're trying to contact as24155 but they are also in
>>>> China and we're just emailing their whois record address.
>>>> 
>>>> If you're nearby and in a position to block/dampen that might be helpful.
>>>> 
>>>> Thx
>>>> 
>>>> - mark
>>>> 
>>>> --
>>>> Mark Jeftovic <mar...@easydns.com>
>>>> Founder & CEO, easyDNS Technologies Inc.
>>>> http://www.easyDNS.com
>>>> 
>>>> 
>>> 

Re: BGP hijack: 64.68.207.0/24 from as133955

[Sandra Murphy]

> On Oct 4, 2017, at 11:29 AM, Theodore Baschak  wrote:
> 
> I noticed when I looked into both of these leaks 3 hours after Clinton's
> message yesterday that I couldn't see them in any of the looking glasses I
> was looking in (including the NLNOG looking glass)
> 
> Looks like things were able to be cleaned up very quickly.

Interesting.

bgp.he.net is still reporting AS133955 as the originator of 64.68.207.0/24.  I 
don’t know what their refresh cycle is.

And, oh look, bgp.he.net points to an RADB proxy registration for the AS133955 
origination.  RADB no longer reports that route object.  But it must have been 
there at some point.

RADB
route:  64.68.207.0/24

descr:  Fleg Asia Telecom Ltd
Proxy-registered route object
origin: AS133955
notify: ipbb-a...@aptg.com.tw
mnt-by: MAINT-AS17709
changed:kiay...@aptg.com.tw 20170830  #05:45:57Z
source: RADB

stat.ripe.net (bless you, RIPE!) shows that 64.68.207.0/24 has been originated 
by AS133955 off and on for the last month (since the RADB route object’s change 
date?) in the BGP Update Activity and Routing History graphs.  And a huge 
flurry of activity yesterday.

Could I be reading all this wrong?  Seems to have been going on for quite a 
while.

—Sandy

P.S.  The other three prefixes mentioned below show similar results in 
bgp.he.net, with route objects proxy registered on 9/25, and similar results in 
stats.ripe.net, with off-and-on announcements, more off than on for these, 
closely timed with the route object registration. 


> 
> 
> 
> Theodore Baschak - AS395089 - Hextet Systems
> https://bgp.guru/ - https://hextet.net/
> http://mbix.ca/ - http://mbnog.ca/
> 
> 
> 
> 
> On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work  wrote:
> 
>> TELUS AS852 has three address blocks hijacked by AS133955 as well.   We
>> have not been able to get in contact with AS24155.  It looks like they
>> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505.
>> 
>> 68.182.255.0/24
>> 74.49.255.0/24
>> 96.1.255.0/24
>> 
>> 
>> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote:
>>> 
>>> as133955 is broadcasting bogus BGP announcement for our netblock
>>> 64.68.207.0/24
>>> 
>>> It's in China, and we're trying to contact as24155 but they are also in
>>> China and we're just emailing their whois record address.
>>> 
>>> If you're nearby and in a position to block/dampen that might be helpful.
>>> 
>>> Thx
>>> 
>>> - mark
>>> 
>>> --
>>> Mark Jeftovic 
>>> Founder & CEO, easyDNS Technologies Inc.
>>> http://www.easyDNS.com
>>> 
>>> 
>> 

Re: Getting an RADB entry removed that was added by a previous peer

[Sandra Murphy]

Job should also have pointed to http://irrexplorer.nlnog.net (notes "Created by 
Job Snijders").  It notes multiple route objects (e.g., 
http://irrexplorer.nlnog.net/search/129.77.0.0/16).  IMHO, worth a look or two 
from time to time for one’s own resources.

—Sandy


> On Sep 13, 2017, at 7:10 AM, Job Snijders  wrote:
> 
> On Wed, 13 Sep 2017 at 13:08, Matthew Huff  wrote:
> 
>> It appears that Reliance Globalcom  (AS6157) added an RADB entry for our
>> prefix (129.77.0.0/16) when we were a peer of theirs years ago, and it
>> was never removed when we ended the relationship. We are ASN 14607.
>> 
>> I've reached out to their support, but does anyone have a suggestion on
>> how I could get this cleaned up if they don't respond?
>> 
> Easy! Email radb-supp...@merit.edu for assistance.
> 
> Kind regards,
> 
> Job

Re: "Defensive" BGP hijacking?

[Sandra Murphy]

> On Sep 13, 2016, at 8:08 PM, Ca By  wrote:
> 
> On Tuesday, September 13, 2016, Doug Montgomery 
> wrote:
> 
>> If only there were a global system, with consistent and verifiable security
>> properties, to permit address holders to declare the set of AS's authorized
>> to announce their prefixes, and routers anywhere on the Internet to
>> independently verify the corresponding validity of received announcements.
>> 
>> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
>> 
>> I now return us to our discussion of network police, questionnaires for
>> network security, and the use of beer as a motivating force.
>> 
>> dougm
>> 
>> 
> Interesting that backconnect has invalid ROA issued
> 
> http://bgp.he.net/AS203959#_prefixes

Well, no, that’s not what the bgp.he.net (live long and prosper!) icons mean.

There is nothing invalid about the ROA.  And BackConnect did not issue it.

The red key means that AS203959 BackConnect Security LLC is announcing routes 
for 181.215.239.0/24, 191.96.128.0/24. etc that are invalid according to the 
RPKI.  Someone else with the right to use 181.215.239.0/24, 191.96.128.0/24. 
etc, created ROAs authorizing some other AS(s) to originate the route.

You can look at the ROAs for those prefixes with red keys in 
http://rpki-browser.realmv6.org (and with the RPKIviz and EOM tools from 
www.securerouting.net).  You can see that there are ROAs for 181.214.0.0/15 for 
AS50673, AS60458, AS61440.  and ROAs for 191.96.0.0/16 for AS61440, AS60458, 
AS29073, AS33182, AS37692.  and ROAs for 191.101.0.0/16 for AS60458, AS37692, 
AS61440.

Except.

It looks like, maybe, BackConnect was re-allocated the four prefixes with red 
keys, and whoever reallocated the prefixes to them created ROAs for their 
aggregate — but not for their customers.  See for example 
http://bgp.he.net/net/191.96.128.0/24 (and 
http://bgp.he.net/net/191.101.191.0/24)

This can occurred as the world backfills the existing allocations and the 
customers don’t keep up and their providers aren’t careful.  Some RPKI 
implementations will warn you that the ROA you are about to create will make 
existing routes appear invalid to the RPKI.

Just for fun, take a look at the IRR entries for the four prefixes with red key 
icons:

route:  191.96.128.0/24
descr:  Clan Servers
origin: AS20473
notify: net-supp...@ap.equinix.com
notify: n...@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed:mvillalo...@ap.equinix.com 20151229
source: NTTCOM

route:  191.96.129.0/24
descr:  Clan Servers
origin: AS20473
notify: net-supp...@ap.equinix.com
notify: n...@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed:mvillalo...@ap.equinix.com 20151229
source: NTTCOM

route:  191.101.191.0/24
descr:  Clan Servers
origin: AS20473
notify: net-supp...@ap.equinix.com
notify: ap-...@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed:mporq...@ap.equinix.com 20151227
source: NTTCOM

route:  181.215.239.0/24
descr:  Proxy route object registered by AS2764
origin: AS45177
remarks:This route object was created by AAPT on behalf of a customer.
remarks:As some of AAPTs upstream networks filter based on IRR objects,
remarks:this route object has been created to ensure that the advertisement
remarks:of this prefix is not rejected.
notify: routing.sha...@aapt.com.au
mnt-by: MAINT-AS2764
changed:nob...@aapt.com.au 20160106
source: RADB

(like the “nobody” part???)


At least the aggregate announcements aren’t proxies.

route:  181.214.0.0/19
descr:  Digital Energy Technologies LTD.
origin: AS61440
mnt-by: MAINT-AS61440
changed:modes...@host1plus.com 20140814  #13:04:53Z
source: RADB

route:  191.101.0.0/21
descr:  Digital Energy Technologies LTD.
origin: AS25761
mnt-by: MAINT-AS61440
changed:modes...@host1plus.com 20150610  #08:53:38Z
source: RADB

—Sandy

(Since bgp.he.net changes as the routing world changes, the red keys could be 
gone by the time anyone looks, of course.)



> 
> On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman >
>> wrote:
>> 
>>> Blake,
>>> 
>>> I concur that these are key questions. Probably _the_ key questions. The
>>> fabric of the Internet is today based on trust, and BGP's integrity is
>> the
>>> core of that trust.
>>> 
>>> I realize that BGP hijacking is not uncommon. However, this is the first
>>> time I've seen in it used defensively. I don't see a way to ever bless
>> this
>>> kind of defensive use without compromising that core trust. If Internet
>>> reachability depends on individual providers believing that they are
>>> justified in violating that trust when they are attacked, how can the
>>> Internet stand?
>>> 
>>> In addition to the question posed to Bryant about whether he would take
>>> this action again, I would like to add: what about the innocent parties

Re: Prefix hijacking by AS20115

[Sandra Murphy]

On Sep 28, 2015, at 11:59 PM, Bob Evans  wrote:

> 
> Would be nice if our membership organization ARIN ( that we all pay to
> keep us somewhat organized) had an ability to do something for you I
> never looked into it...i don't knowmaybe it does ?
> 

No one else has said this, so…

RPKI.  Which ARIN does do.

—Sandy

P.S.  The following has numerous points of weirdness.

about 104.73.161.0/24, RADB says:

route: 104.73.161.0/24
descr: Proxy for Akamai (AS20940) and Roller Networks (AS11170)
origin: AS20115
mnt-by: MAINT-CHTR-WD
changed: tim.we...@charter.com 20150312 #20:32:27Z
source: RADB

route: 104.73.161.0/24
descr: Akamai Technologies
origin: AS20940
mnt-by: AKAM1-RIPE-MNT
changed: unr...@ripe.net 2101
source: RIPE
remarks: 
remarks: * THIS OBJECT IS MODIFIED
remarks: * Please note that all data that is generally regarded as personal
remarks: * data has been removed from this object.
remarks: * To view the original object, please query the RIPE Database at:
remarks: * http://www.ripe.net/whois
remarks: 

route: 104.64.0.0/10
descr: Akamai
origin: AS35994
mnt-by: AKAM1-ALTDB-MNT
changed: abl...@akamai.com 20140518
source: ALTDB




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Note - ARIN Consultation on proposed Registration Services Agreement Now Open

[Sandra Murphy]

There’s been no comment on this announcement on this list, but there were a 
small handful of NANOGers who energetically discussed this on the arin-consult 
list starting mid-August.

On the last day of the comment period (so you might have missed it), a detailed 
comment was submitted, which focussed on the impact to legacy resource holders 
and those who acquire addresses in the transfer market.

I’m not sure how many people on this list would have been following a 
discussion of the ARIN RSA, but there might be some who would find legacy and 
transfer focussed comments to be interesting.

So in case you missed it:

General discussion:  
http://lists.arin.net/pipermail/arin-consult/2015-August/date.html
Focussed comment:  
http://lists.arin.net/pipermail/arin-consult/2015-August/000662.html

—Sandy


On Jul 29, 2015, at 4:11 PM, John Curran  wrote:

> NANOGers -
> 
> To the extent that you are interested in ARIN's Registration Services 
> Agreement, we have
> just initiated a consultation on a proposed new version of the RSA (and 
> LRSA) as noted in
> the attached announcement.   If you wish to provide any feedback, please 
> do so on the
> > mailing list 
> between now and 30 August 2015.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> Begin forwarded message:
> 
> From: ARIN >
> Subject: [ARIN-consult] Consultation on Registration Services Agreement Now 
> Open
> Date: July 29, 2015 at 4:04:03 PM EDT
> To: >
> 
> ARIN is seeking community input on a new version of the Registration
> Services Agreement that combines the existing Registration Services
> Agreement (RSA) and Legacy Registration Services Agreement (LRSA) into a
> single agreement (“RSA Version 12.0/LRSA Version 4.0”).
> 
> Following community consultation and finalization, ARIN will provide
> services to new parties per this latest version of the Registration
> Services Agreement. Existing holders of Internet number resources will
> have the opportunity to upgrade to this new version of the Registration
> Services Agreement or remain with their current Registration Services
> Agreement.
> 
> There are notable and substantive changes with this new version
> incorporating input received from the community on the Registration
> Services Agreements.
> 
> These changes include:
> 
> *  Clarifying that the agreement is only applicable to “Included Number
> Resources” (i.e. the Internet number resources pursuant to the
> agreement, not any other number resources that parties may hold under
> other agreements or no agreement)
> *  Similarly clarifying that the provision wherein a Customer is
> agreeing that “Included Number Resources” are not property is only
> applicable to “Included Number Resources” in the agreement and remains
> silent with regard to any other number resources held by the party
> *  Providing uniform service terms and conditions (other than fees) for all
> customers receiving services from ARIN
> *  Elaborating on the definition of ARIN’s services that are covered by
> the agreement, including resource certification
> *  Providing a more balanced agreement with respect to term language
> previously seen as favorable to ARIN
> 
> The new RSA Version 12.0/LRSA Version 4.0 is available at the following URL:
> 
> https://www.arin.net/resources/agreements/rsa_draft_ver12.pdf
> 
> We strongly encourage you to review the current RSA and LRSA against the
> proposed version of this new agreement and to submit your constructive
> comments to arin-cons...@arin.net.
> 
> Discussion on arin-cons...@arin.net will close on 30 August 2015. ARIN
> seeks clear direction through community input, so your feedback is
> important. If you have any questions, please contact us at i...@arin.net.
> 
> 
> Thank you,
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
> ___
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult 
> Mailing
> List (arin-cons...@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN 
> Member Services
> Help Desk at i...@arin.net if you experience any issues.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Route leak in Bangladesh

[Sandra Murphy]

On Jun 30, 2015, at 10:39 AM, Justin M. Streiner strei...@cluebyfour.org 
wrote:

 On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote:
 
 Randy Bush ra...@psg.com wrote
 A friend in AS58587 confirmed that this was caused by a configuration
 error - it seems like related to redistribution, and they already
 fixed that.
 
 7007 all over again.  do not redistribute bgp into igp.  do not
 redistribute igp into bgp.
 
 I also suggested them to implement BGP community based route filtering
 in their outbound policy.  Any other suggestions or thoughts to
 prevent such incidents in general?
 
 At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) and 
 your downstream customer ASNs.  Whether this is done manually, built using 
 AS-SETs from your route registry of choice, or through some other
 automated means is another story.
 

That sort of AS_PATH filtering would not have helped in this case.  The AS 
originated the routes, it did not propagate an upstream route.

So an AS_PATH filter to just its own AS would have passed these routes.

You would need origin validation on your outbound routes.  Job suggested prefix 
filters on outbound routes.  (If you are doing prefix filters on your inbound 
customer links, it might be excessive caution to also prefix filter customers 
prefixes on outbound links?  Or is it: you can never be too careful, 
belt-and-suspenders, measure twice, etc?)

--Sandy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Route leak in Bangladesh

[Sandra Murphy]

On Jun 30, 2015, at 9:41 AM, Job Snijders j...@instituut.net wrote:

 
 In addition to the BGP community scheme, outbound as-path filters could
 help. Most network's list of transit providers is fairly static, it
 would be easiy with as-path filters to prevent announcing upstream
 routes to other upstreams or peering partners.


Except that this was not a route leak per se.  The announced routes AS_PATH 
shows them as originated by the offending AS, not *propagated* by the offending 
AS. So the outbound AS_PATH did not retain the upstream portion of the path.

--Sandy




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Routing Insecurity (Re: BGP in the Washington Post)

[Sandra Murphy]

On Jun 10, 2015, at 7:51 AM, Russ White ru...@riw.us wrote:

 
 I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying 
 it's is too heavyweight given the tradeoffs, and that we probably started 
 with the wrong questions in the first place.
 
 What's needed is to spend some time thinking about what questions really need 
 to be answered, the lowest cost way to answer those questions, and a complete 
 examination of the tradeoffs involved. Is what path did this update travel, 
 or are the BGP semantics being properly followed, really questions that 
 want asking? Or are there other, more pertinent questions available? 
 

Not liking the solution is not a reason to abandon the problem.  This sounds 
like I don't like eating right and exercising, so keeping my weight under 
control is the wrong question

All protocols rely on certain assumptions of what the fields mean - when you 
send them and when you receive them.  Analyzing a protocol for vulnerabilities 
starts with identifying what happens if those assumptions are broken.  (Like 
the assumption in IP that the source address is the node that sent the packet - 
spoofing breaks that assumption.)  Breaking the semantics creates attacks.

--Sandy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Routing Insecurity (Re: BGP in the Washington Post)

[Sandra Murphy]

There have been suggestions that a key-per-AS is easier to manage than a 
key-per-router, like in provisioning.

Key-per-router was brought up as providing the means to excise one misbehaving 
router that is in some risky sort of environment, which is a different 
management pain.

In terms of security, from outside the AS, you are basing your decisions on 
your trust in the AS in the key-per-AS case, and you are basing your decisions 
on your trust in the AS that certified the router in the key-per-router case.

The local operator's environment and policy rule in choosing the technique.

The draft draft-ietf-sidr-bgpsec-ops-05 says:

   A site/operator MAY use a single certificate/key in all their
   routers, one certificate/key per router, or any granularity in
   between.

--Sandy

On Jun 10, 2015, at 9:17 AM, Russ White ru...@riw.us wrote:

 
 rtfm.  bgpsec key aggregation is at the descretion of the operator.
 they could use one key to cover 42 ASs.
 
 I've been reading the presentations and the mailing lists, both of which
 imply you should use one key per router for security reasons. I would tend
 to agree with that assessment, BTW. 
 
 Russ 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ARIN's RPKI Relying agreement

[Sandra Murphy]

On Dec 4, 2014, at 12:39 PM, John Curran jcur...@arin.net wrote:

 On Dec 4, 2014, at 11:35 AM, Christopher Morrow morrowc.li...@gmail.com 
 wrote:
 


 Note that the claims that could ensue from an operator failing to follow best 
 practices
 and then third-parties suffering an major operational outage is likely to be 
 large


   
 Undertaking that risk to the other services that everyone else presently rely 
 upon 
 (Whois, reverse DNS) is not reasonable 

Which begs the question for me -- ARIN already operates services that operators 
rely upon.  Why are they different?  Does ARIN run no risk of litigation due to 
some perceived involvement of those services in someone's operational outage?

Has there been litigation against ARIN tied to, for example, reverse DNS?  Or 
the IRR?

--Sandy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BGP Security Research Question

[Sandra Murphy]

On Nov 4, 2014, at 8:00 AM, Nick Hilliard n...@foobar.org wrote:

 On 04/11/2014 12:38, sth...@nethelp.no wrote:
 These mechanisms do little or nothing to protect against unauthorized
 origination of routing information. There are plenty of examples which
 say it has *not* been enough, see for instance the Pakistan Telecom -
 Youtube incident in 2008.
 
 mis-origination and related problems are all policy problems rather than
 technical transport issues.  Policy implies human input at some stage along
 the chain, so probably the only way we'll ever see the end of unintended
 prefix leaks is to completely eliminate human input in all aspects of
 routing policy management.
 
 Nick

I see a distinction between policy and authorization.

Policy is something the ISP decides for themselves - I make my own routing 
policy as to what is my best path.

BGP was created to make it possible for operators to have that policy decision.

Authorization is something else.

Prefix holders want to say I authorize the origination of this prefix.  
Operators can decide to enforce that authorization in their policy or not, but 
at least the prefix holder gets to make the determination of what is 
authorized.  (See IRR route objects, RPKI ROAs)

There are those who call route leaks an authorization problem.  [[[I think. 
 They want to be able to say I authorize my neighbor to propagate this 
announcement with the following constraints (no peers, no transit, customers 
only, etc).  [[[I think.]]]  Again, operators could decide to enforce that 
authorization in their policy or not, but those wanting to stop route leaks 
want to make the determination of what is authorized.

Policy is local.

Authorization is global.  (And so it relies on global access to a statement of 
the authorization, aye, there's the rub.)

--Sandy




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BGP Security Research Question

[Sandra Murphy]

On Nov 4, 2014, at 8:45 AM, Yuri Slobodyanyuk y...@yurisk.info wrote:

 Let me disagree - Pakistan Youtube was possible only because their uplink
 provider did NOT implement inbound route filters . As always the weakest
 link is human factor - and no super-duper newest technology is ever to help
 here .

One problem with route filters is that the protection relies on the place 
closest to the problem to detect the leak.

Further on in the network, not as effective.

 As regards to S-bgp/soBGP from technical point of view , wait for the day
 when the vulnerability gets published (SSL-heartbleed style) that
 invalidates all this PKI stuff …

Or the IRRs on which the route filters are built.  (No need for publication of 
a vulnerability.  See recent msgs about already known problems with IRRs.)

--Sandy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

[Sandra Murphy]

Other RIR based RIRs have the same ability to protect prefixes in their realm 
of control.  (See RFC 2725 RPSS)(*)  (I think that APNIC is doing pretty much 
as RIPE is.) 

Even RIPE is not secure for prefixes outside their region.  (There's one 
maintainer that anyone can use to register anything for resources outside the 
region - password publicly available, etc.)

Non-RIR based IRRs do not have the ability to tie the register-er to authority 
for the resource, so they have no base on which to build the RIPE sort of 
security.

--Sandy

(*) (yes, I'm listed as an author, but Curtis Villamizer was far and away the 
principal author.)

On Oct 24, 2014, at 7:20 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote:

 The RIPE IRR is secure. Why not just copy that for the other regions?
 
 Baldur



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

[Sandra Murphy]

 IRR usage, training, tools, and better hygiene, perhaps expressly validated 
 from resource certification from either RPKI

You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests 
using RPKI to protect RPSL objects.

That would help solve the trust problem in the current IRR world, which is that 
most IRRs can't tell if the object being registered is authorized.  RIPE and, I 
think, APNIC being the exception, for their region resources.  Lots of proxy 
registered objects aren't a good sign.

--Sandy


On Oct 23, 2014, at 2:26 PM, Danny McPherson da...@tcb.net wrote:

 soapbox
 
 I think the routing system would be in a much happier [less bad] place if 
 only had a minor amount of the energy and resources that USG (and RIRs) have 
 been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been 
 redirected to lower hanging fruit and better recognizing / leveraging 
 existent systems and operational practices (e.g., more IRR usage, training, 
 tools, and better hygiene, perhaps expressly validated from resource 
 certification from either RPKI or in-addr.arpa, etc).  Given that many of the 
 same derived policies there could also be employed for inter-domain 
 datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing 
 machinery and practices already deployed could more easily accommodate this 
 in the near term, it seems only natural to me.
 
 As for the visionaries playing the long game, they've made progress, but 
 surely the only way to get there is with more incremental putty and small 
 practical steps to fill the gaps at this point.
 
 /soapbox
 
 I for one would like to see ARIN (as well as other RIRs and the adjacent 
 community) invest more pragmatically in this area, particularly given the 
 governance climate and other externalities at play these days.
 
 Alas,
 
 -danny
 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is .gov only for US government agencies?

[Sandra Murphy]

On Oct 21, 2014, at 11:08 AM, David Conrad d...@virtualized.org wrote:

 On Oct 20, 2014, at 10:18 PM, Barry Shein b...@world.std.com wrote:
 Not that anyone is looking for a solution but I suppose one possible
 solution would be to use the two-letter cctld then gov like
 parliament.uk.gov or parliament.ca.gov etc.
 
 No doubt there would be some collisions but probably not too serious.
 
 Folks outside of the US have issues with the US government having a role in 
 the administration of the root, even if that role is to ensure ICANN does 
 screw the pooch.

I'm thinking there's a not missing here. 

--Sandy


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is .gov only for US government agencies?

[Sandra Murphy]

By the time of RFC1591, March 1994, authored by Jon Postel, said:

GOV - This domain was originally intended for any kind of government
 office or agency.  More recently a decision was taken to
 register only agencies of the US Federal government in this
 domain.

No reference as to who, when, or how.

That same RFC says:

   In the Domain Name System (DNS) naming of computers there is a
   hierarchy of names.  The root of system is unnamed.  There are a set
   of what are called top-level domain names (TLDs).  These are the
   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
   letter country codes from ISO-3166.  It is extremely unlikely that
   any other TLDs will be created.

Gotta love that last sentence, yes?

--Sandy

On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) f...@cisco.com wrote:

 
 On Oct 19, 2014, at 5:05 AM, Matthew Petach mpet...@netflight.com wrote:
 
 Wondering if some of the long-time list members
 can shed some light on the question--why is the
 .gov top level domain only for use by US
 government agencies?  Where do other world
 powers put their government agency domains?
 
 With the exception of the cctlds, shouldn't the
 top-level gtlds be generically open to anyone
 regardless of borders?
 
 Would love to get any info about the history
 of the decision to make it US-only.
 
 Thanks!
 
 Matt
 
 The short version is that that names were a process. In the beginning, hosts 
 simply had names. When DNS came into being, names were transformed from 
 “some-name” to “some-name.ARPA”. A few of what we now all gTLDs then came 
 into being - .com, .net, .int, .mil, .gov, .edu - and the older .arpa names 
 quickly fell into disuse. 
 
 ccTLDs came later.
 
 I’ve been told that the reason God was able to create the earth in seven days 
 was that He had no installed base. We do. The funny thing is that you’ll see 
 a reflection of the gTLDs underneath the ccTLDs of a number of countries - 
 .ac, .ed, and the like.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Prefix hijacking, how to prevent and fix currently

[Sandra Murphy]

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 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?
 
 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.

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.



signature.asc
Description: Message signed with OpenPGP using GPGMail