[149405] in North American Network Operators' Group
Re: Thanks & Let's Prevent this in the Future.
daemon@ATHENA.MIT.EDU (Richard Barnes)
Fri Feb 3 08:10:38 2012
In-Reply-To: <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>
Date: Fri, 3 Feb 2012 08:09:43 -0500
From: Richard Barnes <richard.barnes@gmail.com>
To: Arturo Servin <aservin@lacnic.net>
Cc: nanog <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@lacnic.net> wrote:
>
> =A0 =A0 =A0 =A0One option is to use RPKI and origin validation. But it wo=
n'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 is=
sues but at least some fat fingers/un-expierience errors.
>
> =A0 =A0 =A0 =A0We are running an experiment to detect route-hijacks/missc=
onf using RPKI. So far, not many routes are "signed" but at least we can pe=
riodically check our own prefix (or any other with ROAs) to detect some inc=
onsistencies:
>
> 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. =A0It'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. =A0There 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. =A0I took the=
time
>> to register all of my routes, ASNs, etc. =A0However, as I learned today,=
this
>> was probably done in vain. =A0Too 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. =A0So, 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. =A0Additionally, if som=
eone
>> rings your NOC's line an industry-standard process of verifying "ownersh=
ip"
>> and immediately responding by filtering out announcements. There's no se=
nse
>> in allowing a service provider to be impaired because a spammer doesn't
>> want to give up clean IP space. =A0Do you protect a bad customer or the
>> Internet as a whole? =A0I pick the Internet as a whole.
>>
>> How can we prevent anyone else from ever enduring this again? =A0While w=
e 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 Inbo=
x,
>> 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 WHOI=
S
>> was sufficient, apparently I was wrong. =A0Not everyone respects them, b=
ut
>> then again, they aren't very well managed (I've got several networks wit=
h
>> antiquated information I've been unable to remove, it doesn't impair us
>> normally, but its still there).
>>
>> What can we do? =A0Better yet, how do we as a whole respond when we enco=
unter
>> 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
>
