Re: [lisp] Secdir early review of draft-ietf-lisp-nexagon-04

Dear David, thank you again for putting the effort to review the draft.
Published bellow are clarifications to concerns raised.

In summary of main risk mitigations for the lisp-nexagon interface we can say:

  (1) tapping: all communications are through dynamic tunnels therefor may be
  encrypted using IP-Sec or other supported point to point underlay standards
*this are not static, but retunneling routers (RTRs) do all aggregations

  (2) spoofing: it is very hard to guess a MobilityClientEID valid for a short
  period of time. Clients and H3Services EIDs are whitelisted in EdgeRTRs

  (3) impersonating: efforts to use MobilityClients and H3Services RLOCs should
  be caught by the underlying service provider edge and access networks
** we rely on underlay anti-spoofing for RLOCs and provide anti-spoofing for EIDs

  (4) credibility: the interface crowd-sources geo-state and does not assume to
  trust single detections. Credit history can be traced and reflect credentials

  (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and geo-location,
  only AAA is aware of client IDs credentials and credit but not geo-location
***enterprises can bring their own RTRs and if trusted are provisioned to the LISP network
**** AAA is provisioned administratively including credentials and trust

https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-05 <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-05>

Please let us know as soon as you can if you think the concerns are addressed.
All the best,
Sharon

> On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: David Mandelberg
> Review result: Not Ready
> 
> 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?
> 
> 
> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp