From 10b3a84015c02a0cfc575652766e1d3c6a97ad2b Mon Sep 17 00:00:00 2001 From: Jenny Ramseyer Date: Thu, 11 Jan 2024 14:39:36 -0500 Subject: [PATCH 1/2] Security Considerations section Security Considerations, one typo. Adding a section on Security Considerations. Since we are still in discussions around security considerations for the API, I left this one somewhat ambiguous. This is by no means perfect, but now we have something. Trying to get the draft into a minimal reasonable state before we submit for March. from discussions in: https://github.com/bgp/draft-ietf-peering-api/issues/6 https://github.com/bgp/draft-ietf-peering-api/issues/4 --- draft-ramseyer-grow-peering-api.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/draft-ramseyer-grow-peering-api.md b/draft-ramseyer-grow-peering-api.md index 35007c9..dfa9cab 100644 --- a/draft-ramseyer-grow-peering-api.md +++ b/draft-ramseyer-grow-peering-api.md @@ -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 @@ -71,7 +71,12 @@ 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 the initial proposal, this API intended to require PeeringDB-based authentication as the standard. +After further discussion, it was proposed to offer different authentication options, to accomodate the security concerns of different parties. +There are several possible extensions to the authentication model, including RPKI-based authentication, and additional OAuth providers. +For RPKI-based authentication, this document refers to RFC9323. +However, 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. # Protocol (Jenny--this is not up-to-date, but I pasted in what we had in the google doc and will revise) From 970df359642d92f9ff33135cf5d4457da2ec37d5 Mon Sep 17 00:00:00 2001 From: Jenny Ramseyer Date: Fri, 12 Jan 2024 10:42:16 -0500 Subject: [PATCH 2/2] Update draft-ramseyer-grow-peering-api.md Further discussion in https://github.com/bgp/draft-ietf-peering-api/issues/6 --- draft-ramseyer-grow-peering-api.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/draft-ramseyer-grow-peering-api.md b/draft-ramseyer-grow-peering-api.md index dfa9cab..44f4d8b 100644 --- a/draft-ramseyer-grow-peering-api.md +++ b/draft-ramseyer-grow-peering-api.md @@ -72,11 +72,17 @@ All terms used in this document will be defined here: # Security Considerations 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 the initial proposal, this API intended to require PeeringDB-based authentication as the standard. -After further discussion, it was proposed to offer different authentication options, to accomodate the security concerns of different parties. -There are several possible extensions to the authentication model, including RPKI-based authentication, and additional OAuth providers. +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. -However, 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. + # Protocol (Jenny--this is not up-to-date, but I pasted in what we had in the google doc and will revise) @@ -101,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