Hi Rayhaan, Thank you for your comments!
Regarding the OIDC requirement: until RPKI-Signed-Checklists are widely available for use in the industry, we wanted to offer an alternate authentication method for peers. OIDC serves two purposes here: 1. Authentication service until RSC is widely available 2. Alternate (additional?) authentication method—RSC lets the server verify that the client owns the ASN (or peer-related resource), but does not provide any details on “who” the client is. While the identity of the client requestor is not required by the API, some API servers may choose to require an email address, or specific OAuth2 scopes for peering. We received feedback from some users in the industry that they would like to know both “this client owns the asn” and “this client is allowed by their company to do peering,” so adding OIDC as an option seemed like a good way to satisfy that case. Thus, the server could require both OIDC and RSC to pass in order to accept a request, or either of OIDC or RSC, depending on its security preferences. When it comes to implementation, one idea here is for the client and the server to both have a list of authentications that they support. At the time of request, client and server compare those lists, and pick the overlapping set to authenticate. The server is allowed to enforce a required minimum authenticator, if desired. We could add a section to the draft explaining the above, if you think it would be useful? Thanks, Jenny From: Rayhaan Jaufeerally (IETF) <[email protected]> Date: Thursday, June 20, 2024 at 7:02 PM To: Jenny Ramseyer <[email protected]>, Carlos Aguado <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [GROW]Re: Working Group Call for Adoption for draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) Hi and thanks for proposing this draft, I'm excited by the prospect of being able to automate peering configuration setups! After taking a look through the draft I have some comments: As others have already mentioned here the concerns about ZjQcmQRYFpfptBannerStart This Message Is From an Untrusted Sender You have not previously corresponded with this sender. ZjQcmQRYFpfptBannerEnd Hi and thanks for proposing this draft, I'm excited by the prospect of being able to automate peering configuration setups! After taking a look through the draft I have some comments: * As others have already mentioned here the concerns about having only one OIDC provider, that led me to wonder why any OIDC provider is even needed if the proposal allows for RFC9323 signed checklists. That is to say, if you already are able to get signed statements on behalf of an AS (and / or some address prefixes) what does having the additional OIDC step provide in authorizing the RPC? * I think the idea of publishing the URL in WHOIS is a neat way to standardize the distribution of the URLs of these peering API endpoints, one thing that came to mind is if it would make sense to also expose the endpoint via the peering LAN IP of the peer itself, that way you could plausibly keep everything in band (if for example you can authorize the request with RPKI signed checklists alone, then you could have a scenario where a router is able to provision peering sessions somewhat autonomously after being configured on a peering LAN) Best regards, Rayhaan On Thu, Jun 20, 2024 at 3:06 PM Matthias Wichtlhuber <[email protected]<mailto:[email protected]>> wrote: Hi Jenny, Carlos, the proposal sounds good to me. However, I'm still concerned about point (1) from my original email. Do you have any plans to generalize the draft so it doesn't exclusively rely on Peering DB? You've already generalized the draft for identity management, and I think the same should be done for matching peering LAN presences. For example, you could allow multiple types of Peering LAN identifiers from various databases, including but not limited to Peering DB's ixlan id. This approach would give third parties, particularly RIRs, the opportunity to implement the draft if they choose to do so. Regards, Matthias On 14.06.24, 17:12, "Jenny Ramseyer" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> wrote: Hi Matthias, grow, Thank you for the feedback. We can look into adding a diagram to clarify the signing process, along with an overview section to explain the flow. We will try to add something in the next version. Thank you, Jenny Get Outlook for Android <https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>> <https://aka.ms/AAb9ysg><https://aka.ms/AAb9ysg>>;> ________________________________________ From: Matthias Wichtlhuber <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> Sent: Wednesday, June 12, 2024 5:54:05 AM To: Carlos Aguado <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> Cc: [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>> Subject: [GROW]Re: Working Group Call for Adoption for draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) Hi Carlos, grow, IMHO you can improve the security considerations section by adding an introductory high-level overview on the flow between the entities involved, the information passed among them and who signs what before moving into the implementation details. This would probably help to structure the discussion. So more on the use case side. Kind regards, Matthias On 12.06.24, 12:20, "Carlos Aguado" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>>> wrote: Hi grow, Matthias, About your second point. We wrote that specific part with the goal of providing a mini threat model that substantiates the gradual addition of security features we have received inputs on and that mitigate the different levels of risk organizations are willing to support. That section aims to address the need for arbitrary identity providers beyond PeeringDB, and the tie back to RPKI via RSC among others. I would appreciate it if you could please clarify how we can make it easier to parse. Do you expect more or less context on use cases? More or less implementation detail? Best, Carlos On Wed, 12 Jun 2024 at 09:39, Matthias Wichtlhuber <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>>>> wrote: Hi grow, Job, I am in support of this draft. However I have two concerns I would like to raise because I am unsure whether they should be clarified before adoption: (1) The draft bakes in PeeringDB as an identity and information provider. PeeringDB is a great project, but tying a standard to the existence of a specific organization like PeeringDB might be a general concern. (2) I have a hard time parsing the new additions to the security concept in the current revision. The authors might consider clarifying this part before going into an extended discussion (this is more a recommendation than a real concern). If both can be solved after adoption, I am happy to do so on the grow list. Kind regards, Matthias On 07.06.24, 20:13, "Job Snijders" <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank>>> wrote: Dear GROW, The author of draft-ramseyer-grow-peering-api asked whether the GROW working group could consider adoption of their internet-draft. This message is a request to the group for feedback on whether this internet-draft should be adopted. Title: Peering API Abstract: We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. The Internet-Draft can be found here: https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>;> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>>;> <_blank> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/<https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>>;> <_blank>> Please share with the mailing list if you would like this work to be adopted by GROW, are willing to review and/or otherwise contribute to this draft! WG Adoption call ends June 21st, 2024. Kind regards, Job / Chris GROW co-chairs _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank>> To unsubscribe send an email to [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank>> _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank> To unsubscribe send an email to [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>>> <_blank> _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
