Hi Jenny, Thank you for your response and clarification!
It was initially not clear to me that the OIDC mechanism was an optional implementation detail and that it's up to the implementation to choose. I was thinking about it more from the perspective of writing a tool that others would use for their networks, as opposed to a single organization that has their policy and writes their implementation. To that end I think it would make the document clearer if first the specification of the required things one must implement is presented, and then go into some cases of "an implementation may require OIDC for accepting peering requests" etc. Right now the reader sees the diagram in 4.1, then 4.2 says "The diagram below outlines the proposed API flow." and presents OIDC, then 4.3 talks about authentication (which I now realize is in the specific context of the example) which explains OIDC, followed by the schema of the messages, and then only in section 9.3 is the mention of RSC and checking ownership / authorization. Also on the point of the operator choosing what they want to require (OIDC, RSC, etc), would it make sense to have an endpoint that can specify what the requirements are (similar to what you describe with the client and server comparing their requirements, but I think it's not necessary to do a capability like handshake, it should be sufficient for the server to state what it requires and the client then either provides that or notifies the operator that there's an incompatibility)? Thanks, Rayhaan On Fri, Jun 21, 2024 at 7:02 PM Jenny Ramseyer <[email protected]> wrote: > 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]> 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]>> 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>> > ________________________________________ > From: Matthias Wichtlhuber <matthias.wichtlhuber= > [email protected] <mailto:[email protected]>> > Sent: Wednesday, June 12, 2024 5:54:05 AM > To: Carlos Aguado <[email protected] <mailto: > [email protected]>> > Cc: [email protected] <mailto:[email protected]> <[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]>>>> 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 <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]>>>>> > 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]>>> <_blank> <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/%3E>>;> > <_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/%3E>>;> > <_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]>>> <_blank> <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]>>> <_blank> <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]>>> <_blank> > To unsubscribe send an email to [email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto: > [email protected]>>> <_blank> > > > > > > > > > > > > > > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
