Re: [lisp] I-D Action: draft-ietf-lisp-pubsub-13.txt

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) <natal@cisco.com> 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 <lisp-bounces@ietf.org> on behalf of Dino Farinacci <farinacci@gmail.com>
> Date: Thursday, February 16, 2023 at 12:31 AM
> To: lisp@ietf.org list <lisp@ietf.org>
> Cc: i-d-announce@ietf.org <i-d-announce@ietf.org>
> 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, internet-drafts@ietf.org 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
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp