Thanks & Let's Prevent this in the Future.

Richard Barnes richard.barnes at gmail.com
Fri Feb 3 13:09:43 UTC 2012


In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.
<http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html>
<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209>



On Fri, Feb 3, 2012 at 7:16 AM, Arturo Servin <aservin at lacnic.net> wrote:
>
>        One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors.
>
>        We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are "signed" but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies:
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/
>
>
> Regards,
> -as
>
>
> On 1 Feb 2012, at 06:58, Kelvin Williams wrote:
>
>> First off, I'd like to thank everyone on this list who have reached out
>> today and offered us help with our hijacked network space.  It's so
>> refreshing to see that there are still so many who refuse to leave a
>> man/woman down.
>>
>> I'm not going to place any blame, its useless.  There were lies, there were
>> incompetencies, and there was negligence but that is now water under the
>> bridge.
>>
>> However, I think that we as network operators have a duty to each other to
>> make sure we don't allow a downstream customer wreck the operations of
>> another entity who has been rightfully allocated resources.
>>
>> A few months ago, when establishing a new peering relationship I was
>> encouraged (actually required) to utilize one of the IRRs.  I took the time
>> to register all of my routes, ASNs, etc.  However, as I learned today, this
>> was probably done in vain.  Too many people won't spend the extra
>> 30-seconds to verify the information listed there or in ARINs WHOIS.
>>
>> I don't care what a customer tells me, too many times I've found they
>> aren't 100% honest either for malicious/fraudulent reasons or they are
>> unknowing.  So, for our networks or the networks we manage, we want to
>> verify what a customer is saying to prevent what happened to us today.
>>
>> I'd like to get a conversation going and possibly some support of an
>> initiative to spend that extra 30-seconds to verify ownership and
>> authorization of network space to be advertised.  Additionally, if someone
>> rings your NOC's line an industry-standard process of verifying "ownership"
>> and immediately responding by filtering out announcements. There's no sense
>> in allowing a service provider to be impaired because a spammer doesn't
>> want to give up clean IP space.  Do you protect a bad customer or the
>> Internet as a whole?  I pick the Internet as a whole.
>>
>> How can we prevent anyone else from ever enduring this again?  While we may
>> never stop it from ever happening, spammers (that's what we got hit by
>> today) are a dime a dozen and will do everything possible to hit an Inbox,
>> so how can we establish a protocol to immediate mitigate the effects of an
>> traffic-stopping advertisement?
>>
>> I thought registering with IRRs and up-to-date information in ARINs WHOIS
>> was sufficient, apparently I was wrong.  Not everyone respects them, but
>> then again, they aren't very well managed (I've got several networks with
>> antiquated information I've been unable to remove, it doesn't impair us
>> normally, but its still there).
>>
>> What can we do?  Better yet, how do we as a whole respond when we encounter
>> upstream providers who refuse to look at the facts and allow another to
>> stay down?
>>
>> kw
>>
>> --
>> Kelvin Williams
>> Sr. Service Delivery Engineer
>> Broadband & Carrier Services
>> Altus Communications Group, Inc.
>>
>>
>> "If you only have a hammer, you tend to see every problem as a nail." --
>> Abraham Maslow
>




More information about the NANOG mailing list