Skip to main content

Early Review of draft-ietf-lisp-nexagon-04

Request Review of draft-ietf-lisp-nexagon
Requested revision No specific revision (document currently at 53)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2020-10-26
Requested 2020-09-25
Requested by Joel M. Halpern
Authors Sharon Barkai , Bruno Fernandez-Ruiz , Rotem Tamir , Alberto Rodriguez-Natal , Fabio Maino , Albert Cabellos-Aparicio , Jordi Paillisse , Dino Farinacci
I-D last updated 2020-10-08
Completed reviews Secdir Early review of -04 by David Mandelberg (diff)
The working group is approaching completion on this draft, and the authors would like to get ahead of any security issues, so we are requesting an early security review.  Thank you.
Assignment Reviewer David Mandelberg
State Completed
Request Early review on draft-ietf-lisp-nexagon by Security Area Directorate Assigned
Posted at
Reviewed revision 04 (document currently at 53)
Result Not ready
Completed 2020-10-08
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 

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?