Thanks for the email Deb. I hope the updates to -16 satisfy your concerns. See my responses inline to clarify protocol details.
> On Jun 2, 2025, at 8:56 AM, Deb Cooley <[email protected]> wrote: > > 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. > Ah great. Thanks for doing that. > 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. Since draft-ietf-lisp-ecdsa is still a work in progress working group document, you can see authentication and confidentiality support in LISP there. After reading it, you feel it should be referenced, we can do that. > 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. My lispers.net <http://lispers.net/> implemenation uses encryption with both symmetric and asymmetric keys for adding confidentiality to control messages. We can also have control messages encapsulated in LISP data messages using RFC8061 where dynamic keying is supported where draft-ietf-lisp-ecdsa is using configuration of private/public keys pairs. > In addition, expired drafts from three other working groups have been listed. > Has that work merely paused? Or did those I don't know. We have to ask those working groups. > 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? Its possible but there is a bit of obfuscation going on. Since the geo-points are with xTRs and EIDs are behind them and either either staticly resident in campus and data centers or roaming around among xTRs for EID mobility. > Experimental: so a working group can just declare any draft experimental? > Seems odd (and apparently Med may feel the same way). As I said in my previous email, this is an adminstrative status. We need the chairs or AD to respond to this. > 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. OTKs are used to authenticate Map-Replies. We also authenticate Map-Registers and use ECDSA for signing and enrypting Map-Requests and Map-Replies. > If my DISCUSS is not resolved via refusal of the author to cooperate, I will > change my position to ABSTAIN. I am trying to cooperate. I guess you are the ultimate judge. > > ---------------------------------------------------------------------- > > 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. Well this is a function of productivity of the IETF. Sorry to say this but a lot of state and talent has been lost since so much time has passed. > > 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 It depends how the EID is assigned. If its a phyical package and all the contents are addressed out of one EID. That is the entity that is mobile. > > 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? Usually the infra compoennts (LISP boxes that are managed by infra providers) only have acccess to the mapping system. It is very unlikely that users have this access. > > > > 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? See comment right above. > > > > 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. I fixed this. Thanks. > > > > 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? The MSP can configure what EIDs are registered and from where with a SHA-256 signature as well as an ECDSA signature. So authentication of the message, the authorization of the registration, for a given EID from a given RLOC is all controlled by the map-server managed by the MSP. > > > > Section 8, bullet 4: Is it unclear to me how using an authentication > > key/cert > > can be used to encrypt mapping records. There are details about this in draft-ietf-lisp-ecdsa. > > > > 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? I fixed this. > > > > Section 7: What is an xTR? I fixed this. Thanks again, Dino _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
