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
>>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
