Inline w/ [DC]. Plenty of work left to do, thanks for starting it. Deb
On Thu, Jun 5, 2025 at 4:25 PM Dino Farinacci <farina...@gmail.com> wrote: > 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 <debcool...@gmail.com> 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 <debcool...@gmail.com> 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. > [DC] I'm happy to have another draft referenced for this. I assume it will be a normative reference, no? > > 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. > [DC] I have not looked at the ecdsa draft, but I can say categorically that one cannot encrypt data with ECDSA. It is a signature algorithm. If the ecdsa draft also includes ECDH, ECDHE (preferable) or RSA, then those algorithms can indeed be used to establish symmetric keys that can be used in an algorithm such as AES or CHACHA/Poly1305. What precisely did you mean above? > > > 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. > [DC] I can wait. > > > 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. > [DC] if this is the case, perhaps it should be explained in Section 8. > > > 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. > [DC] and then you will incorporate that text in the draft? > > > 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. > [DC] see above....one cannot encrypt using ECDSA. It is not possible. > > > 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. > [DC] I'm happy to give you more time. > > > > ---------------------------------------------------------------------- > > > 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. > [DC] this points to the need for a change then. I've commented on this above. > > > > 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. > [DC] and will a change be made to the draft to make this more obvious? > > > > 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. > [DC] and how is the infrastructure providers access controlled? > > > > > > > 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. > [DC] SHA256 is a hash. ECDSA is a signature. Classically one would hash the data with SHA256 and then sign it with ECDSA. > > > > > > > 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. > [DC] see above > > > > > > > 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. > [DC] perfect, TY > > > > > > > Section 7: What is an xTR? > > I fixed this. > [DC] perfect, TY > > Thanks again, > Dino > >
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
