Hi Geoff, Yep, I agree the text needs to be tightened up.
The way we are looking at this at Cloudflare is that if there's a way to encourage people to use RPKI (including, presumably, helping to make it easier for our customers to use RPKI) to allow us to make the process of onboarding customer-supplied prefixes safer and more efficient, we'd like to make that happen. It seems very likely given the complexity of the real world that this won't be possible in all cases, but perhaps it will be possible in enough cases that it's worth doing. Our experience suggests that we could improve the process for a good proportion of our customers, even if that's not 100% of customers. Joe > On Oct 16, 2024, at 18:25, Geoff Huston <g...@apnic.net> wrote: > > Hi Joe, > > A LOA is used in two ways as far as I can tell: > > a) "please originate a route for my prefix" which is a lot like a > conventional ROA and whats > missing from a ROA is the identification of the 'signer' of the LOA - i.e. > "this request is coming > from one of your customers" and presumably the LOA carries some data to > indicate the > its authenticity. > > b) "please accept a route for my prefix and AS". There is not direct RPKI > counterpart in all cases. > If the prefix is being originated by the AS that is the subject of the LOA > then the pair of the ROA > and ASPA is clear, but what if the prefix is originated one or more AS > hops away? > > Your text is somewhat hand-wavy about the use of an ASPA in such a context > and as ASPAs > don't encompass a prefix, then it's unclear what the appropriate RPKI > objects should be > > Geoff > > > > >> On 17 Oct 2024, at 3:05 AM, Joe Abley <jab...@strandkip.nl> wrote: >> >> Hi Geoff, >> >> Yeah, we talk about how RFC 9323 is useful in the draft. >> >> The point of this doc is not to recommend any particular use of RPKI, but to >> observe more generally that >> >> - if you can demonstrate that you are authorised to originate or propagate a >> prefix using RPKI, manual handling of a LOA is not actually useful[*] >> >> - if you are in a situation where manual handling of a LOA is not useful, >> but you have peers and/or transit providers who require that you send them >> one anyway, it would be nice to have something to send them in place of a >> LOA. >> >> - can we get agreement on the kind of LOA substitute we could agree is >> sensible in this situation? >> >> That's this doc. >> >> >> Joe >> >> [*] you have to suspend disbelief a little bit for this part and imagine >> that there is actually a scenario when a LOA is ever useful >> >> >>> On Oct 16, 2024, at 17:57, Geoff Huston <g...@apnic.net> wrote: >>> >>> surely RFC9323 is relevant here - yes? >>> >>> Geoff >>> >>> >>>> On 17 Oct 2024, at 2:50 AM, Joe Abley <jab...@strandkip.nl> wrote: >>>> >>>> Hi all, >>>> >>>> Per below, Algin and I have written up a proposal that feels grow-ish. >>>> >>>> Hopefully the idea and why we think it's useful is obvious from the text, >>>> but let us know if not and we will explain ourselves. The draft describes >>>> something we are interested in doing at Cloudflare, but we think it's >>>> broader than just one operator and it feels like some shared consensus >>>> about this kind of thing would be useful. >>>> >>>> I have asked Job for a few minutes on the wg agenda in Dublin to discuss, >>>> if there's time. >>>> >>>> >>>> Joe >>>> >>>> Begin forwarded message: >>>> >>>>> From: internet-dra...@ietf.org >>>>> Subject: New Version Notification for >>>>> draft-martin-grow-rpki-generated-loa-00.txt >>>>> Date: October 16, 2024 at 16:14:50 CEST >>>>> To: "Algin Martin" <al...@cloudflare.com>, "Joe Abley" >>>>> <jab...@cloudflare.com> >>>>> >>>>> A new version of Internet-Draft >>>>> draft-martin-grow-rpki-generated-loa-00.txt >>>>> has been successfully submitted by Joe Abley and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-martin-grow-rpki-generated-loa >>>>> Revision: 00 >>>>> Title: Generating a Letter of Agency to reflect RPKI Validity >>>>> Date: 2024-10-16 >>>>> Group: Individual Submission >>>>> Pages: 11 >>>>> URL: >>>>> https://www.ietf.org/archive/id/draft-martin-grow-rpki-generated-loa-00.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-martin-grow-rpki-generated-loa/ >>>>> HTML: >>>>> https://www.ietf.org/archive/id/draft-martin-grow-rpki-generated-loa-00.html >>>>> HTMLized: >>>>> https://datatracker.ietf.org/doc/html/draft-martin-grow-rpki-generated-loa >>>>> >>>>> >>>>> Abstract: >>>>> >>>>> Letters of Agency (LOA) are commonly used to authorise network >>>>> providers to accept and propagate routing information received from >>>>> others. The Resource Public Key Infrastructure (RPKI) can be used to >>>>> perform a similar function, with the advantage that RPKI-signed >>>>> objects can be validated automatically and in a more robust manner >>>>> than manual processing of documents. However, some network operators >>>>> have established processes that expect and require LOAs to be >>>>> exchanged, despite their limitations. This document proposes a >>>>> format for constructing a LOA in the case where RPKI validation is >>>>> available, with the goal of enabling a transition to a future where >>>>> LOAs are no longer needed. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> GROW mailing list -- grow@ietf.org >>>> To unsubscribe send an email to grow-le...@ietf.org >>> >> > _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
