Applying attestation tokens to the open shortest path first (OSPF) routing protocol

1. A method by a first network apparatus configured to operate an Open Shortest Path First (OSPF) routing protocol in a network, comprising:

receiving, from a second network apparatus, an OSPF hello message comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state;

determining that the attestation token is valid for the second network apparatus at a current time;

establishing, in response to the determination, an adjacency to the second network apparatus;

computing, based at least on the attestation token, a trust level for a first link from the first network apparatus to the second network apparatus and a trust level for first prefixes associated with the first link; and

sending, to neighboring network apparatuses, a Link State Advertisement (LSA) comprising the trust level for the first link and the trust level for the first prefixes, wherein the LSA is flooded to one or more network apparatuses in the network, and wherein the trust level for the first link and the trust level for the prefixes are used by the network apparatuses in the network to compute a routing table of the network.

2. The method of claim 1 , further comprising:

receiving, from a third network apparatus, an OSPF message comprising an attestation-capability information associated with the third network apparatus;

determining, based on the attestation-capability information, whether the attestation-capability information associated with the third network apparatus satisfies a pre-determined attestation capability requirement; and

dropping, if the attestation-capability information associated with the third network apparatus does not satisfy the pre-determined attestation capability requirement, any OSPF message originated from the third network apparatus.

3. The method of claim 1 , wherein determining that the attestation token is valid for the second network apparatus at the current time comprises:

forwarding the attestation token and an identity of the second network apparatus to a third-party verifier, wherein the third-party verifier is determined to be trustworthy in the network; and

receiving a response comprising a confirmation that the attestation token is valid for the second network apparatus at a current time.

4. The method of claim 1 , further comprising:

receiving, from a third network apparatus, a second OSPF hello message comprising a second attestation token, wherein the second attestation token is for proving that the third network apparatus is in a known safe state;

determining that the second attestation token fails to be valid for the third network apparatus at a current time; and

processing the second OSPF hello message based on a local policy.

5. The method of claim 4 , wherein the local policy instructs to drop the second OSPF hello message if the second attestation token fails to be valid for the third network apparatus at the current time.

6. The method of claim 4 , wherein the local policy instructs to set a metric of a second link from the first network apparatus to the third network apparatus to a pre-determined value associated with a failed attestation if the second attestation token fails to be valid for the third network apparatus at the current time.

7. The method of claim 4 , wherein the local policy instructs to process the second OSPF hello message regardless of whether the second attestation token is valid for the third network apparatus at the current time.

8. The method of claim 1 , further comprising:

generating a third attestation token using one or more crypto-processors associated with the first network apparatus, wherein the third attestation token is valid for a pre-determined amount of time.

9. The method of claim 8 , further comprising:

adding the third attestation token to every OSPF hello message the first network apparatus sends until a new attestation token is generated after the pre-determined amount of time is elapsed.

10. The method of claim 8 , further comprising:

adding the third attestation token to one or more LSA messages the first network apparatus sends until a new attestation token is generated after the pre-determined amount of time is elapsed.

11. The method of claim 1 , further comprising:

receiving an LSA originated from a fourth network apparatus, wherein the LSA comprises a fourth attestation token that is for proving that the fourth network apparatus is in a known safe state;

determining that the fourth attestation token fails to be valid for the fourth network apparatus at a current time; and

processing the LSA based on a local policy.

12. The method of claim 1 , further comprising:

receiving an LSA originated from a fourth network apparatus, wherein the LSA comprises a trust level for a third link associated with the fourth network apparatus and a trust level for a third prefixes associated with the third link; and

computing, based at least on the LSA from the fourth network apparatus, a routing table of the network, wherein the routing table comprises information regarding the trust level for the third link and the trust level for the third prefixes.

13. The method of claim 12 , wherein the first network apparatus routes a flow over the third link only when the trust level for the third link satisfies the required trust level for the flow.

14. The method of claim 12 , further comprising:

determining that a plurality of routing paths is available for a flow, wherein each of the plurality of routing paths is associated with an identical cost;

computing, for each of the plurality of paths for the flow, a trust score of the path, wherein the trust score is a minimum trust level associated with links within the path; and

selecting a path associated with a highest trust score among the plurality of paths to route the flow.

15. One or more computer-readable non-transitory storage media embodying software that is operable on a first network apparatus that is configured to operate an OSPF routing protocol in a network when executed to:

receive, from a second network apparatus, an OSPF hello message comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state;

determine that the attestation token is valid for the second network apparatus at a current time;

establish, in response to the determination, an adjacency to the second network apparatus;

compute, based at least on the attestation token, a trust level for a first link from the first network apparatus to the second network apparatus and a trust level for first prefixes associated with the first link; and

send, to neighboring network apparatuses, an LSA comprising the trust level for the first link and the trust level for the first prefixes, wherein the LSA is flooded to one or more network apparatuses in the network, and wherein the trust level for the first link and the trust level for the prefixes are used by the network apparatuses in the network to compute a routing table of the network.

16. The media of claim 15 , wherein the software is further operable when executed to:

receive, from a third network apparatus, an OSPF message comprising an attestation-capability information associated with the third network apparatus;

determine, based on the attestation-capability information, whether the attestation-capability information associated with the third network apparatus satisfies a pre-determined attestation capability requirement; and

drop, if the attestation-capability information associated with the third network apparatus does not satisfy the pre-determined attestation capability requirement, any OSPF message originated from the third network apparatus.

17. The media of claim 15 , wherein determining that the attestation token is valid for the second network apparatus at the current time comprises:

forwarding the attestation token and an identity of the second network apparatus to a third-party verifier, wherein the third-party verifier is determined to be trustworthy in the network; and

receiving a response comprising a confirmation that the attestation token is valid for the second network apparatus at a current time.

18. The media of claim 15 , wherein the software is further operable when executed to:

receiving, from a third network apparatus, a second OSPF hello message comprising a second attestation token, wherein the second attestation token is for proving that the third network apparatus is in a known safe state;

determining that the second attestation token fails to be valid for the third network apparatus at a current time; and

processing the second OSPF hello message based on a local policy.

19. The media of claim 18 , wherein the local policy instructs to drop the second OSPF hello message if the second attestation token fails to be valid for the third network apparatus at the current time.

20. A first network apparatus that is configured to operate an OSPF routing protocol in a network comprising:

one or more processors; and

one or more computer-readable non-transitory storage media coupled to one or more of the processors and comprising instructions operable when executed by one or more of the processors to cause the system to:

receive, from a second network apparatus, an OSPF hello message comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state;

determine that the attestation token is valid for the second network apparatus at a current time;

establish, in response to the determination, an adjacency to the second network apparatus;

compute, based at least on the attestation token, a trust level for a first link from the first network apparatus to the second network apparatus and a trust level for first prefixes associated with the first link; and

send, to neighboring network apparatuses, an LSA comprising the trust level for the first link and the trust level for the first prefixes, wherein the LSA is flooded to one or more network apparatuses in the network, and wherein the trust level for the first link and the trust level for the prefixes are used by the network apparatuses in the network to compute a routing table of the network.