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

[David Mandelberg <[e-mail]>]

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
>