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

From: Tero Kivinen via Datatracker <[email-masked]>
Date: Thu, 08 Oct 2020 13:21:20 -0700

Reviewer: David Mandelberg
Review result: Not Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Not ready.

If I understand correctly, 64-bit Client EIDs serve as both 
identification and authentication for a client. How many clients will an 
EdgeRTR know about at a single time? How many EIDs can an attacker guess 
per second? If an attacker can guess 1024 EIDs per second, and there are 
2^32 valid EIDs, I think that would mean it would take about 24 days on 
average to guess a (non-specific) EID. Are my numbers off? Is that 
acceptable?

How does the Client XTR verify the authenticity of the data coming from 
Server XTRs? Is it relying on infrastructure security in the LISP and 
server networks, and the obscurity of its own Client EID? E.g., if a 
non-participant in the LISP network can get the Client EID and RLOC 
(e.g., by sniffing packets), could they spoof an unsolicited multicast 
packet to the client?

If the above is possible, I think this part of the Security 
Considerations section should be fleshed out more, and possibly made 
mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is 
tunneled  and its UDP content may be encrypted"

The Security Considerations section says "The H3ServiceEIDs themselves 
decrypt and parse actual H3-R15 annotations" but as far as I can tell, 
that's the first mention of any mandatory encryption of H3-R15 
information. How does that encryption work?

I assume it wouldn't be that hard for an attacker to get legitimate 
access to a Mobility Client (e.g., by buying a car). What would stop 
them from sending the type of "fake-news" updates the Security 
Considerations section talks about?

---

From: Sharon Barkai <[email-masked]>
Date: Fri, 9 Oct 2020 17:48:03 +0300

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

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 tunnels end to end:
- between EIDClients and EdgeRTRs
- between ingress and egress EdgeRTR
- between EdgeRTRs and H3EIDServices

Depending on the specific  nexagon network as service offered we would like to offer the option to encrypt all communications on these tunnels.

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?

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?

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.

Should we detail these aspects in security considerations ? 

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.   

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

> On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker <[email-masked]> wrote:
>

---

From: Sharon Barkai <[email-masked]>
Date: Fri, 9 Oct 2020 20:32:44 +0300

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.

Nexagon uses LISP overlay encapsulations end to end:
- between EIDClients and EdgeRTRs
- between ingress and egress EdgeRTR
- between EdgeRTRs and H3EIDServices

Depending on the specific  nexagon as service we would like to offer the option to encrypt all communications on these dynamic encapsulations.

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.

Thank you in advance!

--szb
Cell: +972.53.2470068

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 9 Oct 2020 10:57:23 -0700

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

It can be made even harder using more than 64-bits (since we are using IPv6 EIDs). But if you do guess it, there isn't much you can do with it because you don't have context and you can't send packets to it. As an attacker, you can't get the RLOC information to send packets to the guessed EID.

Registrations and lookups to the mapping system can only done by provisioned nodes in a centralized secure enclave.

Dino

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 9 Oct 2020 21:27:56 +0300

Sharon Barkai writes:
> Tero, 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.

I was not the reviewer, the review was done by David Mandelberg, but
for some reason his review emails did not get delivered to the secdir
list, and I filled them in to the datatracker on his behalf and thats
why the datatracker sent the emails out as coming from me to secdir
and other lists. For discussion about the draft and review, you better
contact him. 

> 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.
> 
> Depending on the specific  nexagon network as service offered we would like to
> offer the option to encrypt all communications on these tunnels.
> 
> 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?
> 
> 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?
> 
> 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.
> 
> 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.   
> 

-- 
[email-masked]

---

From: Sharon Barkai <[email-masked]>
Date: Sat, 17 Oct 2020 14:24:15 +0300

Dear David, thank you again for putting the effort to review the draft.
Published bellow are clarifications to concerns raised.

In summary of main risk mitigations for the lisp-nexagon interface we can say:

  (1) tapping: all communications are through dynamic tunnels therefor may be
  encrypted using IP-Sec or other supported point to point underlay standards
*this are not static, but retunneling routers (RTRs) do all aggregations

  (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

  (3) impersonating: efforts to use MobilityClients and H3Services RLOCs should
  be caught by the underlying service provider edge and access networks
** we rely on underlay anti-spoofing for RLOCs and provide anti-spoofing for EIDs

  (4) credibility: the interface crowd-sources geo-state and does not assume to
  trust single detections. Credit history can be traced and reflect 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
***enterprises can bring their own RTRs and if trusted are provisioned to the LISP network
**** AAA is provisioned administratively including credentials and trust

https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-05 <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-05>

Please let us know as soon as you can if you think the concerns are addressed.
All the best,
Sharon

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: David Mandelberg <[email-masked]>
Date: Mon, 19 Oct 2020 19:34:35 -0400

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

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

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.

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

> 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

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 20 Oct 2020 08:34:16 +0300

> On Oct 20, 2020, at 02:34, David Mandelberg <david=[email-masked]> 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!

> No worries. I'm just glad I noticed that my initial review email didn't go through. Hopefully this one does?
> 
> 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?
> 
> 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 routers (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.

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

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

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

>> WhatsApp: +1.650.492.0794

This is the updated related security considerations text in https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06 <https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06>

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

---

From: David Mandelberg <[email-masked]>
Date: Tue, 20 Oct 2020 22:12:07 -0400

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=[email-masked] 
>> <mailto:david=[email-masked]>> wrote:
>>
>> went through due to an email server misconfiguration. Sending again 
>> now that my email issues are fixed, I think)
> 
> Made it!
> 
>>
>>> 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?
>>
>> 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.
>>> 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?
>>
>> 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./
> 
>>
>>> 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.
>> 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.
>>> whitelist provisioned by the AAA to the EdgeRTR given to the client 
>>> as an anchor.
>>> 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.
>> 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.
> 
> 
>>
>>> 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.
>>
>>> 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
> This is the updated related security considerations text in 
> https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06
> 
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Sharon Barkai <[email-masked]>
Date: Wed, 21 Oct 2020 17:21:52 +0300

Thanks David, everyone, for the time and attention for the review. Its not taken for granted. 

--szb
Cell: +972.53.2470068

> On Oct 21, 2020, at 05:12, David Mandelberg <david=[email-masked]> wrote:
> 
> Thanks, draft-ietf-lisp-nexagon-06 addresses all of my concerns. (And sorry about the email issues and associated delays.)
> 
>>>> On Oct 20, 2020, at 02:34, David Mandelberg <david=[email-masked] <mailto:david=[email-masked]>> wrote:
>>> 
>> 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./
>>> 
>> This is the updated related security considerations text in https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06