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 <farina...@gmail.com> 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 -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
