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

[Sharon Barkai <[e-mail]>]

Thanks David, everyone, for the time and attention for the review. Its not taken for granted. 

--szb
Cell: +972.53.2470068
WhatsApp: [phone]

> On Oct 21, 2020, at 05:12, David Mandelberg <david=[e-mail]> wrote:
> 
> Thanks, draft-ietf-lisp-nexagon-06 addresses all of my concerns. (And sorry about the email issues and associated delays.)
> 
> On 10/20/20 1:34 AM, Sharon Barkai wrote:
>>>> On Oct 20, 2020, at 02:34, David Mandelberg <david=[e-mail] <mailto:david=[e-mail]>> wrote:
>>> 
>>> (I previously sent the email below on 2020-10-10, but I don't think it went through due to an email server misconfiguration. Sending again now that my email issues are fixed, I think)
>> Made it!
>>> 
>>> On 10/9/20 1:32 PM, Sharon Barkai wrote:
>>>> Sorry for the confusion, David! 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.
>>> 
>>> No worries. I'm just glad I noticed that my initial review email didn't go through. Hopefully this one does?
>>> 
>>>> 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 overlay encapsulations end to end:
>>>> - between EIDClients and EdgeRTRs
>>>> - between ingress and egress EdgeRTR
>>>> - between EdgeRTRs and H3EIDServices
>>> 
>>> That doesn't cover "The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations" though, right? Is there any encryption of the H3-R15 information all the way from EIDClient to H3EIDService?
>>> 
>>>> Depending on the specific  nexagon as service we would like to offer the option to encrypt all communications on these dynamic encapsulations.
>>>> 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?
>>> 
>>> You understand the specifics of where this protocol will be used much better than I do, so I think you're in a better place to choose between picking one option or explaining the issues and letting implementers decide on the encryption mechanism. In general, I'd lean towards picking one good cipher suite and sticking to that (without making it difficult to change things up in the future), but there can be good reasons not to do that.
>> I think we are in sync. Encryption is on a tunnel by tunnel basis (or dynamic encapsulation to be more accurate) to and from the LISP edge tunnel router/s (EdgeRTRs), IPSec by default, leaving room for work like lisp-crypto and lisp-wiregaurd being done, but not coupling the clients and servers in that respect. There is still unclarity about the mismatch between car-compute and edge-compute hw/sw updates and depreciation, and car-compute and the car itself for that matter./
>>> 
>>>> 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?
>>> 
>>> I think so, yes. I generally think it's good to be explicit when relying on underlying infrastructure for security, so that if anybody later tries to adapt a protocol to some different infrastructure, they know what to pay attention to.
>> Done.
>>> 
>>>> 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.
>>> 
>>> Oh, I didn't realize incoming packets on the EdgeRTR were dropped if the source EID doesn't match the RLOC associated with that EID. I thought that was a typical roaming case. If an attacker has to guess both a valid EID and its matching RLOC, I suspect that makes the attack much more difficult. (Though still far from impossible, depending on how many EID-RLOC pairs an EdgeRTR knows about at a time and how many guesses the attacker can get. IP allocation for the RLOC would play a huge factor too. If an ISP allocates RLOCs sequentially, it might be much easier to guess than if RLOCs are random /128s within guessable /64s. Though if an attacker can sniff RLOCs, the math changes again.)
>> Right. LISP Mapped Overlay in this context is used to load-balance clients as they network-login, and to “map-reduce” compute aggregation to EID context. There is no change of EID-RLOC binding due to random roaming. EID-RLOC pairs are whitelisted in EdgRTRs by AAA and dev-ops.
>>> 
>>>> Should we detail these aspects in security considerations ?
>>> 
>>> Yes please.
>> Done.
>>> 
>>>> 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.
>>> 
>>> Sounds good, even if you mention it only at a high level. I think the fact that H3EIDServices are sharing reputation information back to the AAA service is important to mention.
>> Done.
>>> 
>>>> 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]
>> This is the updated related security considerations text in https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06
>> In summary of main risk mitigations for the lisp-nexagon interface we can say:
>>   (1) tapping: all communications are through dynamic tunnels therefore may be
>>   encrypted using IP-Sec or other supported point to point underlay standards.
>>   These are not static tunnels but lisp re-tunneling routers (RTRs) perform all
>>   nexagon Overlay aggregation.
>>   (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,
>>   Clients using the AAA procedure, H3Services via dev-ops.
>>   (3) impersonating: efforts to use MobilityClients and H3Services RLOCs should
>>   be caught by the underlying service provider edge and access networks. EID
>>   impersonating is caught by EdgeRTR EID RLOC whitelist mismatch.
>>   (4) credibility: the interface crowd-sources geo-state and does not assume to
>>   trust single detections. Credit history track to MobilityClientEIDs by as part
>>   of normal H3Services fact checking, aggregate scores affect AAA 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.
>>   aggregate credit score span all H3Services administratively without source.
>> _______________________________________________
>> secdir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview