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
