Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: DM
-
Labels:None
-
Team:Architecture
Description
The current situation including encryption for north america is covered
in DMTN-108 (https://dmtn-108.lsst.io/) - this should be updated to
cover Europe to keep this all in one place.
Attachments
Issue Links
- is duplicated by
-
- Invalid
Activity
I've got a few comments, and have asked network architects to also look at it. I will combine comments and post to the ticket as soon as I hear back.
Jeff Kantor
added a comment - I've got a few comments, and have asked network architects to also look at it. I will combine comments and post to the ticket as soon as I hear back. It appears i have waited several months for those comments Jeff Kantor - if they arrive i will take a new ticket - or you can make a PR against master.
merged for now
That is fine, I pinged Jeronimo again on this last NET meeting and again today in email. He owes us suggestions on encryption in Layer 2 or 3 of the network. Once we get that, we can decide whether to include or not. Otherwise, no comments are expected.
Jeff Kantor
added a comment - That is fine, I pinged Jeronimo again on this last NET meeting and again today in email. He owes us suggestions on encryption in Layer 2 or 3 of the network. Once we get that, we can decide whether to include or not. Otherwise, no comments are expected. Here are the comments from Jeronimo Bezerra on encryption options:
Ignoring scenarios where an attacker would have physical access to the Summit, Base, or Archive Datacenters, there are a few scenarios we could tackle to protect the data flows:
1) Encrypt the data before sending it from Summit or Base. If we encrypt the payload (image and reports), we would add a layer of complexity to unauthorized access. Decrypting it won’t be an extremely challenging using current technology, but by the time the payload is decrypted, that information is no longer useful (assuming the satellites are constantly moving). It will require CPU and memory, probably going to make payload larger and delay transfers by [milli]seconds. However, it is doable.
2) On top (recommended) of option #1 or in parallel (not recommended), we could add a layer of protection by encrypting at Layer 4 (Transport) using TLS. Easy to implement, not expensive. It will require CPU and memory, probably going to make payload larger and delay transfers by [milli]seconds. However, it is doable.
3) Encrypting at Layer 3 using IPSEC from source to the destination:
a. If done from the Distributors/Forwarders: It will require CPU and memory, probably going to make payload larger. It will increase OPEX and demand engagement from the IT team. However, it is doable.
b. If a new IPSEC appliance is used to encrypt traffic from all Distributors/Forwarders: Single going to failure, high CAPEX, low OPEX once it is deployed. Better than #3.a
4) Encrypting at Layer 2 using MACSEC: Juniper has routers capable of doing it at line-rate. However, we would need to understand what to do in the path from Chile to NCSA. High CAPEX, Medium OPEX.
5) Encrypting at Layer 1: Surreal (nearly impossible) CAPEX. Low OPEX. It only makes sense when combined with one or more options above. Ideal for Summit to Base. Not for international connectivity.
Jeff Kantor
added a comment - Here are the comments from Jeronimo Bezerra on encryption options:
Ignoring scenarios where an attacker would have physical access to the Summit, Base, or Archive Datacenters, there are a few scenarios we could tackle to protect the data flows:
1) Encrypt the data before sending it from Summit or Base. If we encrypt the payload (image and reports), we would add a layer of complexity to unauthorized access. Decrypting it won’t be an extremely challenging using current technology, but by the time the payload is decrypted, that information is no longer useful (assuming the satellites are constantly moving). It will require CPU and memory, probably going to make payload larger and delay transfers by [milli] seconds. However, it is doable.
2) On top (recommended) of option #1 or in parallel (not recommended), we could add a layer of protection by encrypting at Layer 4 (Transport) using TLS. Easy to implement, not expensive. It will require CPU and memory, probably going to make payload larger and delay transfers by [milli] seconds. However, it is doable.
3) Encrypting at Layer 3 using IPSEC from source to the destination:
a. If done from the Distributors/Forwarders: It will require CPU and memory, probably going to make payload larger. It will increase OPEX and demand engagement from the IT team. However, it is doable.
b. If a new IPSEC appliance is used to encrypt traffic from all Distributors/Forwarders: Single going to failure, high CAPEX, low OPEX once it is deployed. Better than #3.a
4) Encrypting at Layer 2 using MACSEC: Juniper has routers capable of doing it at line-rate. However, we would need to understand what to do in the path from Chile to NCSA. High CAPEX, Medium OPEX.
5) Encrypting at Layer 1: Surreal (nearly impossible) CAPEX. Low OPEX. It only makes sense when combined with one or more options above. Ideal for Summit to Base. Not for international connectivity.
Jeff Kantor please have a look at https://dmtn-108.lsst.io/v/DM-22072/index.html