> I may have missed something, but I think that in the case of the first > notify, it does actually start at the Itr. > Specifically, it starts with an ItR sending a subscribe request. The MS > responds to that with a notify. What I am suggesting is that (when security > is desired) the Itr includes the same kind of information in its subscribe > that goes into lisp-sec. And that the reply, instead of going directly from > the MS back to the ITR goes through the ETR so that the rest of the lisp-sec > procedures can be applied.
Yes, and in that Subscribe-Request you can include an OTK. But that one-time-key would be used more than one time. To send the Map-Notify to reply with the RLOC-set to the ITR as well as acknowledger from the Map-Server that subscription has been accepted. But then the one-time-key would have to be *stored* in the Map-Server and then used later when the RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key would be “two time” and we would set a precedent to make it no longer ephemeral. In previous cases, the OTK was not stored anywhere. > I would then use that as a bootstrap, putting necessary secrets to create the > key information so that the MS can sign and the ITR can verify future > notifies that go directly from the MS to the ITR. If the working group believes that the OTK should be stored and then used again, then both the Map-Server and ITR would have to store it. In the original case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is received. But the Map-Server would have to store it indefinintely (per ITR that subscribes). Dino > > Yours, > Joel > > On 3/31/2020 1:33 PM, Dino Farinacci wrote: >>> thinking about Alberto's request, and reading the document, I wondered if >>> the security could be improved by sending the first notify back via the >>> ETR, and coupling it to LISP-SEC to protect the information and provide >>> needed keys for further messages? It seems like we do need a way to protect >>> the notifications, and requiring associations from every ITR to every MS >>> who may provide notifications seems impossible. >> You can’t use LISP-SEC because the transactional nature of it starts with an >> ITR and a one-time-key, that is used to signed Map-Replies returning to it. >> For Map-Notify messages send from Map-Server via ETR, there would be no ITR >> one-time-key. And if the Map-Server used its own one-time-key, the ITR >> couldn’t derive it. Note with LISP-SEC the map-server one-time-key is >> derived from the ITR’s one-time-key in the Map-Request. >> Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
