Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-22072

Update DMTN-108 to include european network

    XMLWordPrintable

    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

            Activity

            Hide
            womullan Wil O'Mullane added a comment -
            Show
            womullan Wil O'Mullane added a comment - Jeff Kantor please have a look at   https://dmtn-108.lsst.io/v/DM-22072/index.html  
            Hide
            jkantor 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.

            Show
            jkantor 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.
            Hide
            womullan Wil O'Mullane added a comment - - edited

            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.

            Show
            womullan Wil O'Mullane added a comment - - edited 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.
            Hide
            womullan Wil O'Mullane added a comment -

            merged for now

            Show
            womullan Wil O'Mullane added a comment - merged for now
            Hide
            jkantor 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.

            Show
            jkantor 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.
            Hide
            jkantor 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.

             

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

              People

              Assignee:
              womullan Wil O'Mullane
              Reporter:
              womullan Wil O'Mullane
              Reviewers:
              Jeff Kantor
              Watchers:
              Jeff Kantor, Robert Blum, Wil O'Mullane
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.