> Inline w/ [DC]. Plenty of work left to do, thanks for starting it. Thanks for your email Deb. See my responses inline. I trimmed a bit to make email more readable but include your latest commentary text.
> 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? I can't keep track of these rules anymore. The working group chairs can comment on this point. I'll do whatever they recommend. > > 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? My implementation encyrpts with ChaCha2020 but RFC8061 has 5 cyphers that can be used. I never said ECDSA was used for encryption. > > > 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. Can someone coordinate this, like Jim since those working groups may be under his umbrella? > > 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. I will add some more text to section 8. Thanks. > > 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? Luigi/Padma, tell me what I should write to satisfy this comment. > > 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. Typo. LISP implementations do the following: (1) SHA-256 to hash the Map-Register with a configured shared password to support authorization. (2) ECDSA to sign the Map-Register to authenticate the ETR. (3) Chacha20 or cyphers in RFC8061 to encrypt any message. > > 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? No. The use-cases are described for a high-level reference, not a detailed specification for the specific use-case. > > > 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? Just like DNS servers, load balancers, firewalls, routers, etc. A lot of my commentary was to help you understand the protocol and history of LISP. The total document series exists to we can segment the design into modular parts and then reference them from other documents. So we have to make sure we don't repeat text and cause confusion or contradiction because the Proposed Standard drafts can't change. Dino _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
