# BGPsec

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.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2Fe8coAcqPQfv70pSs6ZhU%2FUntitled.png?alt=media&#x26;token=f9e40bc9-d6d4-4e39-93d9-e4efadd20d51" alt=""><figcaption></figcaption></figure>

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.

### Summary <a href="#id-7f47c7bb-889a-4d54-8120-561af48f023a" id="id-7f47c7bb-889a-4d54-8120-561af48f023a"></a>

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.

### Further Reading/Watching <a href="#id-3de4bfbb-6942-4d73-bba2-f1c25646d09e" id="id-3de4bfbb-6942-4d73-bba2-f1c25646d09e"></a>

<https://www.rfc-editor.org/rfc/rfc8205>

\
<https://www.internetsociety.org/blog/2017/10/bgpsec-reality-now/>

\
<https://packetpushers.net/bgpsec-basic-operation/>

\
<https://www.youtube.com/watch?v=qN9SBaX1DYg&ab_channel=NANOG>
