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

[David Mandelberg <[e-mail]>]

(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)

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.

> 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.

> 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.)

> Should we detail these aspects in security considerations ?

Yes please.

> 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.

> 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]