Early Review of draft-ietf-lisp-nexagon-04
review-ietf-lisp-nexagon-04-secdir-early-mandelberg-2020-10-08-00

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?