Can RPKI be used with routes that are not being advertised at the moment? As in to sign a route that *could* be there, but is not there presently. There's been several BGP hijacks that I've followed closely that involved hijacking IP space as well as the ASN that would normally originate it. I'm wondering if having valid ROAs/RPKI would have helped in this case or not. Theodore Baschak - AS395089 - Hextet Systems
Hi, the creation of a ROA does not require the announcement of the prefix. Creation of a ROA, prefix announcement, and validation of the prefix are decoupled. If you are the legitimate resource holder you can create a ROA for this prefix (even if you don't advertise the prefix). As soon as the prefix is advertised, third parties can validate based on the created ROA. However, in case the hijacker is able to use the legitimate origin ASN, the validation outcome would be valid. You would need to assign the prefix to an ASN that cannot be hijacked or is dropped for other reasons. (Or do BGPsec. ;) Cheers matthias On Mon, 13 Jun 2016, Theodore Baschak wrote:
Can RPKI be used with routes that are not being advertised at the moment? As in to sign a route that *could* be there, but is not there presently.
There's been several BGP hijacks that I've followed closely that involved hijacking IP space as well as the ASN that would normally originate it. I'm wondering if having valid ROAs/RPKI would have helped in this case or not.
Theodore Baschak - AS395089 - Hextet Systems
On Mon 2016-Jun-13 17:53:45 -0500, Matthias Waehlisch <m.waehlisch@fu-berlin.de> wrote:
Hi,
the creation of a ROA does not require the announcement of the prefix. Creation of a ROA, prefix announcement, and validation of the prefix are decoupled. If you are the legitimate resource holder you can create a ROA for this prefix (even if you don't advertise the prefix). As soon as the prefix is advertised, third parties can validate based on the created ROA.
However, in case the hijacker is able to use the legitimate origin ASN, the validation outcome would be valid. You would need to assign the prefix to an ASN that cannot be hijacked or is dropped for other reasons. (Or do BGPsec. ;)
Would this not be a valid use case for creating an ROA with origin AS 0? RFC7607[1] Autonomous System 0 was listed in the IANA Autonomous System Number Registry as "Reserved - May be use [sic] to identify non-routed networks" ([IANA.AS_Numbers][2]). [RFC6491] specifies that AS 0 in a Route Origin Attestation (ROA) is used to mark a prefix and all its more specific prefixes as not to be used in a routing context. This allows a resource holder to signal that a prefix (and the more specifics) should not be routed by publishing a ROA listing AS 0 as the only origin. To respond to this signal requires that BGP implementations not accept or propagate routes containing AS 0. RFC6491[3] AS 0 ROA: A ROA containing a value of 0 in the ASID field. "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)" [RFC6483] states "A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context. With the most detail in RFC6483[4]. Yes/no?
Cheers matthias
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Mon, 13 Jun 2016, Theodore Baschak wrote:
Can RPKI be used with routes that are not being advertised at the moment? As in to sign a route that *could* be there, but is not there presently.
There's been several BGP hijacks that I've followed closely that involved hijacking IP space as well as the ASN that would normally originate it. I'm wondering if having valid ROAs/RPKI would have helped in this case or not.
Theodore Baschak - AS395089 - Hextet Systems
[1]https://tools.ietf.org/html/rfc7607#section-1 [2]https://tools.ietf.org/html/rfc7607#ref-IANA.AS_Numbers [3]https://tools.ietf.org/html/rfc6491#section-4 [4]https://tools.ietf.org/html/rfc6483#section-4
Hi, yes. In this context the discussion at IETF92 might be interesting: https://www.ietf.org/proceedings/92/minutes/minutes-92-sidr (search for "Extemporaneous Presentation") Cheers matthias On Tue, 14 Jun 2016, Hugo Slabbert wrote:
On Mon 2016-Jun-13 17:53:45 -0500, Matthias Waehlisch <m.waehlisch@fu-berlin.de> wrote:
Hi,
the creation of a ROA does not require the announcement of the prefix. Creation of a ROA, prefix announcement, and validation of the prefix are decoupled. If you are the legitimate resource holder you can create a ROA for this prefix (even if you don't advertise the prefix). As soon as the prefix is advertised, third parties can validate based on the created ROA.
However, in case the hijacker is able to use the legitimate origin ASN, the validation outcome would be valid. You would need to assign the prefix to an ASN that cannot be hijacked or is dropped for other reasons. (Or do BGPsec. ;)
Would this not be a valid use case for creating an ROA with origin AS 0?
RFC7607[1]
Autonomous System 0 was listed in the IANA Autonomous System Number Registry as "Reserved - May be use [sic] to identify non-routed networks" ([IANA.AS_Numbers][2]).
[RFC6491] specifies that AS 0 in a Route Origin Attestation (ROA) is used to mark a prefix and all its more specific prefixes as not to be used in a routing context. This allows a resource holder to signal that a prefix (and the more specifics) should not be routed by publishing a ROA listing AS 0 as the only origin. To respond to this signal requires that BGP implementations not accept or propagate routes containing AS 0.
RFC6491[3]
AS 0 ROA: A ROA containing a value of 0 in the ASID field. "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)" [RFC6483] states "A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
With the most detail in RFC6483[4].
Yes/no?
Cheers matthias
participants (3)
-
Hugo Slabbert -
Matthias Waehlisch -
Theodore Baschak