Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security Considerations section #8

Merged
merged 2 commits into from
Jan 12, 2024
Merged

Security Considerations section #8

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
10b3a84
Security Considerations section
jramseyer Jan 11, 2024
970df35
Update draft-ramseyer-grow-peering-api.md
jramseyer Jan 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 14 additions & 3 deletions draft-ramseyer-grow-peering-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ By using the Peering API, entities requesting and accepting peering can signific

* Reducing in person-hours spent configuring peering
* Reducing configuration mistakes by reducing human interaction
* And by peering, reducing network latency through expansion of interconneciton relationships
* And by peering, reducing network latency through expansion of interconnection relationships



Expand All @@ -71,7 +71,18 @@ All terms used in this document will be defined here:

# Security Considerations

PeeringDB OAuth will be the minimum requirement for authorization of API requests.
As peering connections exchange real internet traffic, this API requires a security component to verify that the requestor is allowed to request peering on behalf of that ASN.
In this initial proposal, this API requires PeeringDB-based authentication as the standard.
After further discussion, the authors decided to offer alternate authentication options to accomodate the security concerns of different parties.
As peers may require varying security standards, this API will support PeeringDB OIDC as the base requirement, with optional security extensions in addition (RPKI or alternate OIDCs, for example)
This document hopes that, through the RFC process, the Working Group can come to a consensus on a base "authentication standard," to ease adoption for peering partners.

Of particular interest is RPKI.
PeeringDB OIDC allows the API to verify who the requesting party is, while RPKI-signing allows the requesting party to prove that they can configure a request.
The combination of both authorizations provides a strong security guarantee.
This document recognizes that not all partners have the time or engineering resources to support all authorization standards, so the API will offer an extensible security platform to meet varying security requirements.
For RPKI-based authentication, this document refers to RFC9323.


# Protocol
(Jenny--this is not up-to-date, but I pasted in what we had in the google doc and will revise)
Expand All @@ -96,7 +107,7 @@ TODO: Update this spec, include API endpoints
* Request source

## Request flow
1. AUTH phase: initiator makes an authenticated request to receiver via PeeringDB OAUTH. This provides the receiver with initiator’s credentials to verify who they say they are
1. AUTH phase: initiator makes an authenticated request to receiver via PeeringDB OIDC. This provides the receiver with initiator’s credentials to verify who they say they are
2. REQUEST phase:
1. ADD: What is the initial information provided
* Your ASN
Expand Down