I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Not ready. If I understand correctly, 64-bit Client EIDs serve as both identification and authentication for a client. How many clients will an EdgeRTR know about at a single time? How many EIDs can an attacker guess per second? If an attacker can guess 1024 EIDs per second, and there are 2^32 valid EIDs, I think that would mean it would take about 24 days on average to guess a (non-specific) EID. Are my numbers off? Is that acceptable? How does the Client XTR verify the authenticity of the data coming from Server XTRs? Is it relying on infrastructure security in the LISP and server networks, and the obscurity of its own Client EID? E.g., if a non-participant in the LISP network can get the Client EID and RLOC (e.g., by sniffing packets), could they spoof an unsolicited multicast packet to the client? If the above is possible, I think this part of the Security Considerations section should be fleshed out more, and possibly made mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is tunneled and its UDP content may be encrypted" The Security Considerations section says "The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations" but as far as I can tell, that's the first mention of any mandatory encryption of H3-R15 information. How does that encryption work? I assume it wouldn't be that hard for an attacker to get legitimate access to a Mobility Client (e.g., by buying a car). What would stop them from sending the type of "fake-news" updates the Security Considerations section talks about?