[174206] in North American Network Operators' Group
Re: Prefix hijacking, how to prevent and fix currently
daemon@ATHENA.MIT.EDU (Sandra Murphy)
Fri Aug 29 06:17:18 2014
X-Original-To: nanog@nanog.org
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <20140829100815.GO44548@Vurt.local>
Date: Fri, 29 Aug 2014 06:17:09 -0400
To: Job Snijders <job@instituut.net>
Cc: nanog@nanog.org, Sandra Murphy <sandy@tislabs.com>
Errors-To: nanog-bounces@nanog.org
--Apple-Mail=_4192EBE0-9FB3-47DF-9AA7-981E46DDA00A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Aug 29, 2014, at 6:08 AM, Job Snijders <job@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
>>=20
>> clearly i am missing something. got a write-up?
>=20
> I'll attempt to clarify.
>=20
> Assume:=20
>=20
> ROA: 10.0.0.0/16, max_length =3D 16, origin =3D AS123
> in RIB: 10.0.0.0/16 origin AS123 (valid)
>=20
> 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'
>=20
> Loose mode A would look like this:
>=20
> 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.
>=20
> Loose mode B would look like this:
>=20
> 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.
>=20
> 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.
>=20
> 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.
--Apple-Mail=_4192EBE0-9FB3-47DF-9AA7-981E46DDA00A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJUAFMlAAoJEHplpQeet0IZuBUP/3aVfDVKZiEs54huEeEoNnr2
fbHKf4Bd36ZM7IPiTyAe5kMQW9MKfqAhGRTN7MwSvZxuXK8XksxhszCSiZgWIIWL
mv/B0jMQA3V3jt7KWNpXGRtca+Ad65Xe1hXDnyu43TQEY9qjaKG86NdoIk7VgaXD
VEYasc7q1wSkOgY/yxmEExuCwPy/gk07KmvVRxoEljjXTRM84UeT0fFyCie3pY6x
uncJSSVlqnTDjsxJy34e9Wp4ubB2Ugo4Ro/qyNlb+FgcKDmr+eCFkpNJfeSilAg7
aFuTXfeSUAG4wBIu4nIlNxH70d6TIWScSXsCKMY/gOJEw2rdCSVquAjn7FvNSWKe
A5TK498VZB0lHtXTx/MvzyJdC6gcPvtKVCbHkK00QtJh7IYMyi1lHEJ+48RVbmeX
05rl4UgooaFCNpr/J5NpVTECJ2SxQz5UbqXF/DtAJa9sHv61ibG1lmAfUtB9jofg
PRVxv1byebt7+MjEr/tqSG//1KBL+BCx2bmmQ/nujFlPtJYPGdvv3J66PQnjBAuF
+Psmdci/97QXetFxo6JbiQTtxJV/rC65kYaLtLo+fGvH01CV1mCQ6QFo7LrVvPmN
HtW+8muM3nsDbf5Mn3EUvIzwUyjWB8rmq8c0YkfWFhRwOOXTq75oeVM2YB0BIHkg
2f6ooqeTUciSs1HClpFX
=UYjq
-----END PGP SIGNATURE-----
--Apple-Mail=_4192EBE0-9FB3-47DF-9AA7-981E46DDA00A--
