Thanks David, everyone, for the time and attention for the review. Its not taken for granted.
--szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Oct 21, 2020, at 05:12, David Mandelberg > <[email protected]> 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 >>>> <[email protected] >>>> <mailto:[email protected]>> 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: +1.650.492.0794 >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
