But the references you provide, suggest that configuration information is required so the verification can be performed. The text in the PubSub document is just too general. I would add, that verification is done through configuration.
Dino > On Feb 20, 2023, at 10:37 AM, Alberto Rodriguez-Natal (natal) > <[email protected]> wrote: > > Dino, > It is not the intention of the specification to recommend or to prescribe > how deployments will enforce the recommendations in 1.1. Rather than focus on > implementation examples, the reader should focus on the recommendations > themselves. Please also consider that while the implementation of the > recommendations in Section 1.1 of PubSub is left out of scope, these > recommendations are in the same “order of magnitude” of similar out-of-scope > recommendations/assumptions made on the main LISP specs, some examples: > “The Mapping System is aware of which EIDs an ETR can advertise. How those > keys and mappings are established is out of scope for this document.” – RFC > 9301, Section 9 > “[…] a Map-Server MUST verify that all EID-Prefixes registered by an ETR > match the configuration stored on the Map-Server.” – RFC 9301, Section 9 > “Similarly, Map-Register security, including the right for a LISP entity to > register an EID-Prefix or to claim presence at an RLOC, is out of the scope > of LISP-SEC.” – RFC 9303, Section 7.1 > “The Mapping System is secure and trusted, and for the purpose of these > security considerations, the Mapping System is considered as one trusted > element. ” – RFC 9301, Section 9 > With that perspective, we believe the recommendations made for PubSub do not > depart too much from the tone set by the general LISP > recommendations/assumptions. > Thanks, > Alberto > From: lisp <[email protected]> on behalf of Dino Farinacci > <[email protected]> > Date: Thursday, February 16, 2023 at 12:31 AM > To: [email protected] list <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [lisp] I-D Action: draft-ietf-lisp-pubsub-13.txt > Comment: > <PastedGraphic-2.png> And how does a Map-Resolver verify a Map-Request? > There is no security association with it unless it uses > draft-ietf-lisp-ecdsa-auth. > And what does "an xTR is allowed to use" mean? Based on what, a white-list > in the Map-Resolver, which is intractable? > And for point (2), how does the Map-Server know which are legit > Map-Resolvers? > This text is hand-waving with no support text to say how it does it. > Dino > > > On Feb 15, 2023, at 2:47 PM, [email protected] wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol WG of the > IETF. > > Title : Publish/Subscribe Functionality for the Locator/ID > Separation Protocol (LISP) > Authors : Alberto Rodriguez-Natal > Vina Ermagan > Albert Cabellos > Sharon Barkai > Mohamed Boucadair > Filename : draft-ietf-lisp-pubsub-13.txt > Pages : 21 > Date : 2023-02-15 > > Abstract: > This document specifies an extension to the request/reply based > Locator/ID Separation Protocol (LISP) control plane to enable > Publish/Subscribe (PubSub) operation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-13 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-13 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
