Just to be clear ABSTAIN is an absolute last resort. And I would expect that it might block publication, if there is no support to resolve by the author.
Deb On Mon, Jun 2, 2025 at 10:44 AM Deb Cooley <[email protected]> wrote: > I am also top posting, since there is literally no responses to my > individual comments. > > I have taken a couple of minutes to skim RFCs 9300, 9301, and 9303, and it > is my opinion that this experiment changes the threat model used in those > RFCs. > > For example, RFC9303 Section 1 states: "a set of security mechanisms > that provides origin authentication, integrity, and anti-replay protection > to LISP's EID-to-RLOC mapping data conveyed via the mapping lookup process. > LISP-SEC also enables verification of authorization on EID-Prefix claims in > Map-Reply messages, ensuring that the sender of a Map-Reply that provides > the location for a given EID-Prefix is entitled to do so according to the > EID-Prefix registered in the associated Map-Server. " But nowhere in that > description is there anything about confidentiality of the data stored in > the mapping database. > > Before this experiment, the threat model for LISP mostly pointed to > integrity, redirecting traffic, and denial of service concerns. Even in > that situation, secure distribution of the OTKs was out of scope. And, in > fact, there is no privacy consideration section in RFC9303. With this > experiment, there is the additional threat to maintain the privacy of the > location of a user who is using a device. Given there is no > confidentiality here, it is difficult to see how tracking a user (via his > device) can be prevented. The use cases described also point to tracking > devices even though Section 8's last sentence mentions completely different > situations. > > In addition, expired drafts from three other working groups have been > listed. Has that work merely paused? Or did those working groups come to > the realization that adding the ability to geo locate network devices opens > a way of enabling the tracking of users behind those devices? > > Experimental: so a working group can just declare any draft > experimental? Seems odd (and apparently Med may feel the same way). > > While a couple of my questions can be answered by skimming RFCs 9300-9303 > (authentication is done via secretly distributed OTKs), the RFCs you > pointed me to only raise more questions. > > If my DISCUSS is not resolved via refusal of the author to cooperate, I > will change my position to ABSTAIN. > > Deb Cooley > > > > > > On Fri, May 30, 2025 at 6:33 PM Dino Farinacci <[email protected]> > wrote: > >> All your questions can be answered by reading (and understanding) RFC9301 >> and its accompanied references to the LISP security IDs and RFCs. The basic >> defintions are in RFC9300. >> >> And as for the references to expired drafts, is is not like this draft >> went out of its way to find an expired drafts. This lisp-geo draft was >> written when they were active and a multi working group coordinated effort >> was made to keep the encodings in sync. Since this may be the only >> non-expiring draft with respect to the encoding, we don't want to lose the >> history and hence why I want to keep it in. >> >> The draft is experimental because that is the status of the document the >> working group wants it to be. >> >> I don't believe we need to make any document updates for your DISCUSSes >> or COMMENTs. >> >> Dino >> >> >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > Section 1, paragraph 2, and Section 4.1, last sentence: Saying that the >> > encoding format is consistent with the encoding documented in I-Ds >> which have >> > all expired over 6 years ago is disingenuous at best. Please either >> remove >> > these sections and sentence entirely, or find examples of RFCs or >> current I-Ds. >> > >> > Section 4.1, para 3: Is there a limit to what a 'physical shipping >> package' >> > can be? How are people's movements prohibited from being a part of >> this use >> > case? Are there privacy concerns that surround the tracking of >> packages? At >> > the very least it would seem to have supply chain implications. Who is >> > permitted to access the database and how do they do that? >> > >> > Section 4.2, paragraphs 4 and 5: This section discusses look-ups of the >> > mapping system. Who is permitted to do this, what authentication and >> > authorization is required? Is any of this information transmitted over >> > unprotected transport? >> > >> > Section 4.2, last paragraph: The I-D referenced here is old and >> expired, is >> > there a more current reference? This use case is especially sensitive, >> > tracking vehicles, either has implications for supply chain, or privacy >> > implications for people. >> > >> > Section 7: What protects the MSP from cross contamination between their >> > customers? Is there a mandatory ID management system required? Side >> channel >> > leakage protection? Authorization system requirements? >> > >> > Section 8, bullet 4: Is it unclear to me how using an authentication >> key/cert >> > can be used to encrypt mapping records. >> > >> > Section 8, last sentence: None of the use cases in Section 4 give this >> > impression. The privacy concerns for a well know public structures or >> > landmarks are much different than package tracking and vehicle tracking. >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > Thanks to Prachi Jain for their secdir review >> > >> > General: This draft is marked as Experimental. What is the >> experiment? How >> > will we know whether it was successful? >> > >> > Section 4.1: ETR? RTR? expand on first use? >> > >> > Section 7: What is an xTR? >> >> >>
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
