(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: +1.650.492.0794
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
