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 <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/>>> > <_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/>>> > <_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]
