Hi all, I've made a fork of Krill with support for this draft. It's available at https://github.com/as207960/krill (and https://github.com/as207960/rpki-rs for the required updates to rpki-rs).
Haven't written any docs yet but the gist of it is: POST https://localhost:3000/api/v1/cas/test-ca/pad Authorization: Bearer correct-horse-battery-staple Content-Type: application/json { "update": [ { "asn": 210561, "peering_api_uri": "https://example.com/peering"; } ], "remove": [] } There is an example PAD file available at rsync:// rpki-repo.as207960.net/repo/q-test-ca/1/AS210561.pad ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Fri, 2 Aug 2024 at 19:18, Jenny Ramseyer <ramseyer= 40meta....@dmarc.ietf.org> wrote: > Hi Q and Job, > > > > Thank you both for the draft and discussion! > > > > I will add a section to draft-ramseyer-grow-peering-api to reference your > document here. As our draft stands now, it’s missing details around API > discovery, so thank you for writing something up here. I will include it > in our upcoming revision. > > > > For those not at the GROW meeting, the consensus after the meeting was > that API discovery should follow: > > 1) First, discover from RPKI > > 2) failing that, fall back to a record in WHOIS > > 3) failing that, query some external source (peeringDB or the like) > > > > Regarding the URI restrictions, enforcing that the URL does not contain a > query string nor a trailing slash makes sense to me. If we can try to reduce > the client-side url parsing requirements, that seems like a nice benefit. > > > > Jenny > > > > *From: *Q Misell <q=40as207960....@dmarc.ietf.org> > *Date: *Thursday, August 1, 2024 at 3:19 AM > *To: *Job Snijders <job=40fastly....@dmarc.ietf.org> > *Cc: *grow@ietf.org <grow@ietf.org>, sidr...@ietf.org <sidr...@ietf.org> > *Subject: *[GROW] Re: [Sidrops] Peering API Discovery > > Thanks for the input on the ASN. 1. I wasn't sure on what string type to > use (there's so many to pick from!) so a second perspective is great. The > additional restrictions on the URI come from me thinking it unclear what's > supposed > > Thanks for the input on the ASN.1. I wasn't sure on what string type to > use (there's so many to pick from!) so a second perspective is great. > > > > The additional restrictions on the URI come from me thinking it unclear > what's supposed to happen if there's a query string etc in the URL. > > Does a base URI of https://example.net/peering?k=v > <https://urldefense.com/v3/__https:/example.net/peering?k=v__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkEzIr9g4$> > then mean every request has to include that query parameter (e.g. > https://example.net/peering/locations?asn= > <https://urldefense.com/v3/__https:/example.net/peering/locations?asn=__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkFJEIWCF$> > 65536&k=v)? > > This seems like extra unnecessary processing work for clients. A > similar logic of client processing applies to the trailing slash > restriction; > > all endpoints in the API are defined with a / at the start, and if there > is no trailing slash in the PAD object then a client can string concatenate > without extra processing. > > > > As for the authority I've seen enough cockups in authority parsing in URIs > that it makes sense to me to forbid it entirely, as the API already > includes its own authentication. > ------------------------------ > > Any statements contained in this email are personal to the author and are > not necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > registered in Wales under № 12417574 > <https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkIvpFoSZ$>, > LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 > <https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkH5mlUCq$>. > UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. > South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered > office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, > trading as Glauca Digital, is a company registered in Estonia under № > 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo > are registered trademarks in the UK, under № UK00003718474 and № > UK00003718468, respectively. > > > > > > On Wed, 31 Jul 2024 at 14:01, Job Snijders <job= > 40fastly....@dmarc.ietf.org> wrote: > > Dear Q, > > I'd revise the ASN.1 as following: > > * use IA5String so the peeringApiUri field is somewhat similar to an > AccessDescription (which is a GeneralName CHOICE to an IA5String), > what you'd also find in a SubjectInfoAccess or AuthorityInfoAccess. > * Define after first use (as appears to be the common style) > * Disallow AS 0 > * > s/id-mod-rpki-peering-api-discovery-2024/id-mod-rpkiPeeringApiDiscovery-2024/g > > ---- > > RpkiPeeringApiDiscovery-2024 > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs-9(9) smime(16) modules(0) > id-mod-rpkiPeeringApiDiscovery-2024(TBD) } > > DEFINITIONS EXPLICIT TAGS ::= > BEGIN > > IMPORTS > CONTENT-TYPE > FROM CryptographicMessageSyntax-2010 -- RFC 6268 > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; > > ct-peeringApiDiscovery CONTENT-TYPE ::= > { TYPE PeeringAPIDiscovery IDENTIFIED BY > id-ct-peeringApiDiscovery } > > id-ct-peeringApiDiscovery OBJECT IDENTIFIER ::= > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs-9(9) id-smime(16) id-ct(1) peeringApiDiscovery(TBD) } > > PeeringAPIDiscovery ::= SEQUENCE { > version [0] INTEGER DEFAULT 0, > asn ASID, > peeringApiUri IA5String } > > ASID ::= INTEGER (1..4294967295) > > END > > ---- > > The in the natural language description of the fields there is a > mismatch: peeringApiUri vs peeringApiUri. I'd use peeringApiUri. I also > agree that it should contain a valid HTTPS URI, but am not sure the > additional restrictions such as query or trailing slash have any value. > I'd remove everything what comes after "MUST NOT include". > > Kind regards, > > Job > >
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
