[174255] in North American Network Operators' Group
Re: Prefix hijacking, how to prevent and fix currently
daemon@ATHENA.MIT.EDU (Saku Ytti)
Tue Sep 2 11:33:06 2014
X-Original-To: nanog@nanog.org
Resent-From: Saku Ytti <ytti@pob.ytti.fi>
Resent-To: nanog@nanog.org
Date: Tue, 2 Sep 2014 18:27:54 +0300
From: Saku Ytti <saku@ytti.fi>
To: "'nanog@nanog.org'" <'nanog@nanog.org'>
In-Reply-To: <9a7467f302e1430c9420ad7399402f61@BN1PR09MB0274.namprd09.prod.outlook.com>
Errors-To: nanog-bounces@nanog.org
On (2014-09-02 14:44 +0000), 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 scenario but
> the 'Loose' mode operation would accept/install D's route.
> Am I right about that? If yes, that is the side effect or CON that I was trying to highlight.
Absolutely, thanks I now understood you and we're on the same page. Loose only
protects routed networks, it do not protect hijacked non-routed prefixes.
> Further, later in a mature stage of RPKI, when nearly all operators have
> implemented the paragraph I cited from RFC 7115, then routers can drop 'Loose' mode.
Yes, many may have sufficient confidence to turn off loose mode at later time.
All of them would be able to gather data during loose-period about actual
occurrence of false positives. Perhaps that is always 0 or at least has been 0
for past several years, this might be make it easy to give accurate data of
factual business risks.
--
++ytti
