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

[Tero Kivinen <[e-mail]>]

Sharon Barkai writes:
> Tero, really want to thank you for putting in the time, you clearly
> understood the draft completely and point to areas we invested
> thought on but can improve the wording.

I was not the reviewer, the review was done by David Mandelberg, but
for some reason his review emails did not get delivered to the secdir
list, and I filled them in to the datatracker on his behalf and thats
why the datatracker sent the emails out as coming from me to secdir
and other lists. For discussion about the draft and review, you better
contact him. 

> Before adjusting the draft would like to rehash together with the
> group, Joel, and Luigi the themes pointed, which are spot on, so to
> reach the best possible language.
> 
> 1) End to end encryption -
> 
> Nexagon uses LISP tunnels end to end:
> - between EIDClients and EdgeRTRs
> - between ingress and egress EdgeRTR
> - between EdgeRTRs and H3EIDServices
> 
> Depending on the specific  nexagon network as service offered we would like to
> offer the option to encrypt all communications on these tunnels.
> 
> We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies RFC2631 key
> exchange over LISP tunnels, also DTLS was suggested.
> 
> Should we determine one or just describe the geo privacy and commercial
> exposure if encryption is not used, especially on the tunnels between
> MobilityEIDClients and EdgeRTRs?
> 
> 2) Spoofing and imposters - 
> 
> EdgeRTRs and H3EIDServices are provisioned in the service provider edge
> network. EdgeRTRs which are added to the network are provisioned with the
> mapping system, H3EIDServices are whitelist provisioned with their designated
> EdgeRTRs.
> 
> We rely on the edge network routers to detect and stop spoofing using industry
> standard double-lookup source/dest  mechanisms.
> Should we state so?
> 
> The MobilityEIDClients are behind mobile access networks and go through AAA
> step before receiving ephemeral EIDs and EdgeRTR  RLOCs as anchors. 
> 
> This EID is based on their client ID credentials, and this EID is whitelist
> provisioned by the AAA to the EdgeRTR given to the client as an anchor. 
> 
> The ipv6 EIDs given to these clients reflect their credibility reputation and
> authorization level to pub-sub into the nexagon network. It is going to be
> very hard to guess a valid EIDClient which an EdgeRTR expects after AAA to
> whitelist provision. These EIDs are temporary and expire after 15 minutes.
> 
> Spoofed EIDClients which are sniffed are going to be detected by the EdgeRTRs
> because of mismatched client RLOC. Spoofed client RLOCs are detected by the
> mobile packet core.
> 
> Should we detail these aspects in security considerations ? 
> 
> 3) Fake news and client trust -
> 
> This is a higher level concern as it is with many other protocols. Privacy and
> reputation require trade-offs. The lisp-nexagon network uses crowd-sourced
> street sampling to reflect current geo-state. Even the most honest client may
> still be wrong, have faulty vision gear, gps interruption, or buggy AI.
> Malicious clients may try to manipulate geo-state to their advantage, clear
> their path from traffic, or simply try to saw confusion. 
> 
> For this reason all detections are corroborated and trust level of each client
> is constantly scored by the H3EIDServices and updates the AAA system. This
> credit score update reflects the behavior of  the assigned ephemeral client
> EID not the client, a car for ecample. But the AAA system knows which client
> ID credentials the EID map to. The AAA system does not need to know the geo
> association of these EID scores. They can be aggregated from all H3EIDServices
> before handed to AAA.
> 
> We can describe this general behavior even though its part of management and
> orchestration and not part of the LISP-Nexagon interface specification.   
> 
> After we clear these 3 key items to everyone satisfaction we can quickly turn
> around the doc to one more iteration. 
> 
> Thank you in advance!
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: [phone]
> 
>     On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker <[e-mail]>
>     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?

-- 
[e-mail]