BGPsec
Last updated
Last updated
BGPsec is a relatively new security extension for BGP that is meant to preform path validation. RFC8205 was published in 2017.
In BGPsec, two eBGP peers advertise support for BGPsec in the OPEN message. BGPsec is a capability. A peer can either support the ability to receive BGPsec Updates, advertise BGPsec Updates, or both receive and advertise BGPsec Updates. This capability is for either IPv4, IPv6, or both.
When a BGP speaker advertises a BGPsec Update, it replaces the AS_PATH attribute with a BGPsec_PATH attribute. The BGPsec_PATH attribute is like the AS_PATH attribute but each hop is cryptographically validated using RPKI. The BGPsec_PATH and AS_PATH attributes are mutually exclusive - only one can be present in an Update.
The major difference between the BGPsec_PATH and AS_PATH attribute is that the router adds the AS that it is advertising the path to in the BGPsec_PATH attribute. (This is called forward path signing). This prevents other ASs from “claiming” to have a path to the route which they don’t have. An example will help explain this.
In the diagram above, AS 65000 is originating the prefix 192.0.2.0/24. We’ll imagine that, for whatever reason, AS 65001 does not want to advertise this to 65002. AS 65004 should only use the path (65003, 65001, 65000).
AS 65000 originates the route with a BGPsec_PATH attribute that signs the fact that the AS path is currently (65000) and also includes the fact that it is only advertising this to 65001. When AS 65000 receives this advertisement, it uses RPKI to validate the BGPsec_PATH attribute, and adds its own AS, adds the fact that it is being advertised only to 65003, and signs it.
This process prevents AS 65002 from being able to hijack the 192.0.2.0/24 route. AS 65002 cannot pretend that it received an Update from 65001, because 65001 signs on its Updates that it is only advertising to 65003. When AS 65004 gets a path from 65002 that says it went (65000, 65001, 65002), AS 65004 knows this is wrong because 65002 cannot forge 65001’s crypographic signature and pretend that 65001 really intended to advertise the prefix to itself.
This is the major difference between BGPsec_PATH and AS_PATH. BGPsec_PATH includes the “intention” of which ASs are to receive the Update. In doing this, the entire AS_PATH is validated.
BGPsec is intended to be used in conjunction with BGP origination validation in order to completely prevent prefix hijacking. Origin validation ensures that the AS that announces the prefix has the rights to announce that prefix, and BGPsec validates the AS path through which the route has been advertised.
As far as I can see, BGPsec is not yet implemented on IOS-XE or IOS-XR.
