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 <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
