5. Security in the IPN

1. Introduction 2. Inter-Internet Dialogs 3. Building a stable Backbone for the IPN 4. IPN Nodes 5. Security in the IPN 6. Deployed Internets in the IPN 7. Working conclusions

5. Security 5.1. Introduction - Overview Currently no users so difficult to plan detailed security mechanisms it s yet sure THAT security is required: Interplanetary Internet will be interesting for hackers, due to limited bandwidth little hacking success fatal would be fatal a lot of private and precious data will be sent in the IPN applied at application layer until now orientation on the E-Mail security mechanisms and services on earth s internet Aspects: protection of IPN infrastructure and protection of the data ( bundles ) exchange routing information and manage routing securely

5. Security 5.2. Required security mechanisms Access control limited access protects against overloading by unauthorized application Authentication required, verify identity of the source of network traffic Data integrity ensure that received data is the same as initially sent across the IPN should make unauthorized modification of data detectable Data privacy provide confidentiality only those who are authorized to obtain traversing data should have access

5. Security 5.3. Types of security paradigms hop-by-hop security ( link security ) data including routing informations protected at source, must be unprotected at each trusted routing point in order to route before sending to next point, data including routing information is reprotected and then send problem: depending on what is defined as a protected area (are gateways trusted?), data is potentially vulnerable to modification or disclosure end-to-end security no trusted gateways, everything on the path between source and destination is seen as hostile so data protected at source, never unprotected until destination routing information must remain unprotected

5. Security 5.4. End-to-end Security end-to-end paradigm preferred, but several problems to solve end-to-end security requires end-to-end protocols and a protocol below the data that provides ability to route so end-to-end protection can only be applied to the data itself and on no layer beyond -> the same way SSL (Secure Sockets Layer) and secure email techniques (S/MIME, OpenPGP) work important to leave packet's protocol headers open for intermediate systems because Interplanetary Internet is very email-like (non-interactive, parties don t necessary have communicated before), this possibility is discussed more intensive

5. Security 5.5. Secure E-Mail technology (1) Encryption, Digitally Signatures (Authentication) -> Public key cryptography Encryption: E-Mail sender uses public key of recipient to encrypt the data, recipient uses his private key to decrypt Digitally Signatures: E-Mail sender uses his private key to sign the message, recipient verifies message the public key of the sender

5. Security 5.5. Secure E-Mail technology (2) Problems public key cryptography needs a lot of processor power public key cryptography needs a lot of bandwidth necessary that all communication parties know each others public keys and exchanging some random information ( Diffie-Hellmann- Exchange ) therefore near-real-time-environment needed, which is not practical in the IPN difficulties to communicate with unknown parties

5. Security 5.5. Secure E-Mail technology (3) A way to solve at least one problem? Symmetric keys could save processor power (encryption and decryption easier), but are not usable in IPN (no save way to send the key) Idea for encryption: E-Mail sender encrypts data with a brand new generated symmetric key and uses Public Key Cryptography only to encrypt the key itself data data Symmetric key Symmetric key encrypted data Recipient s public key Recipient s private key encrypted data encrypted key encrypted key

5. Security 5.5. Secure E-Mail technology (4) Digitally signatures: sender creates a hash of the message with a common algorithm (MD5, SHA-1,...) only the hash is signed with Public Key Cryptography: data data Hash Algorithm Senders private key Senders public key Hash Algorithm data data signed hash signed hash still additional bandwidth required, no solution for that for communication with new parties it s necessary to find out their public key

5. Security 5.6. Using Secure E-Mail Technology in the IPN (1) for making the system work, a public key infrastructure (PKI) will be needed in the IPN even only on earth several problems about that: competing PKIs, how to cross-certify public keys? who is the root certification authority of the whole system? personal public keys are spread by public key-servers or attached on E-Mails in the IPN: public key servers won t work in the same way as on earth - problem similar to the difficulties with the DNS-System as described

5. Security 5.6. Using Secure E-Mail Technology in the IPN (2) not possible to contact PKI-servers on Earth (delays!) local server might exist, but would quickly drop out of synchronization, -> certificates change solution: PKI-servers only on earth, only contactable by earth-based senders Entities not on earth get a set of preplaced public keys of IPN entities to which communication makes sense IPN sender shall always include their public key in every bundle ->costs additional bandwidth, but solves the delay-problem

5. Security 5.7. Protecting the IPN infrastructure important, that no unidentified entities can join network so every entity must authenticate itself verify identity, access controls to allow communication infrastructure information (routing updates, node management information,...) need to be protected the same security mechanisms as for data seem to be possible in that case, hop-by-hop-security a good choice bundle aware application (bundle-agent), signs or encrypts the special infrastructure payload receiving IPN node must check the signature by comparing to access control list

6. Deployed Internets in the IPN 6.1. Introduction Examples for a deployed internet, possible configurations: single lander hosting interplanetary gateway cooperating robots on a foreign planet, maybe communication via low-orbiting satellites that contain interplanetary gateways spacecraft-onboard networks earth s internet

6. Deployed Internets in the IPN 6.2. Applications of deployed internets Until now only basic ideas, model will maybe never reflect actual use of the IPN: 1 return of scientific data usually not time-sensitive except power considerations 2 telemetry information, often as unreliable transmission, delivery either stream-oriented or periodically 3 command and control of in-situ elements, endpoint could be separated by interplanetary space, has to be designed to work with necessary delays (Quality of service!) 4 telescience and virtual presence, great volumes of information, great chances, but still development needed

6. Deployed Internets in the IPN 6.3. Characteristics compared to earth s internet (1) Energy Problems internet on earth mostly wired networks, cheap energy mobile ad hoc networks (MANET) use the same cheap power On other planets the only power is the sun, relativ inefficient diminishes on moving away from sun (Mars Orbit: less than half W/m² as on earth), even more dramatic on surface of planet dictates a need for efficient protocols at all layers Signal-to-noise ratios very high in wired networks in terrestrial MANETs lower will be VERY low in deployed internets (power!)

6. Deployed Internets in the IPN 6.3. Characteristics compared to earth s internet (2) Routing infrastructure on earth mostly fixed, only satellites mobile in IPN: will be nearly only mobile, many satellites, will use mainly radio frequency even for permanent stations Costs installing and running a network on earth very cheap on other planets very expensive: landing, deploying, operating and repairing as much infrastructure as possible should be low-orbiting satellites only antennas for wideband communication on planets to keep costs as low as possible

6. Deployed Internets in the IPN 6.4. Characteristics of protocol layers (1) Actual realization still in development Physical layer: use of radio-frequency spectrum not regulated until now certain frequency bands very attractive for use in space Link layer: manage low Signal-to-Noise ratios by using different coding schemes, e.g. convolutional coding, concatenated codes (Reed Solomon code), Turbo codes each code has different properties for different characteristics reserve resources for control operations link-layer status detection (availability, capacity, congestion, current errors), report to network layer

6. Deployed Internets in the IPN 6.4. Characteristics of protocol layers (2) Network Layer: routing protocols for fast and slow moving mobile nodes in combination with fixed nodes vertical handoffs, adapt changes in links on lower layers mechanisms for self-configuration of the mobile elements (address allocation, name-to-address binding, dynamic hierarchical organization) Transport Layer new protocols for power efficient communication schemes between mobile entities, must be able to adapt to changing network conditions some links will have asymmetric data rates, important to handle this and stay power efficient

6. Deployed Internets in the IPN 6.4. Characteristics of protocol layers (3) Application layer enable service location, necessary at startup and after networks became partitioned monitoring the status and health of mobile nodes 6.5. Comments not possible to guarantee any capacity in deployed network power limitations will be a problem for a long time exchange of components often not possible, important to build a robust system that is easy to repair (autonomously?)

7. Working conclusions all future space missions include vehicles which have to communicate with another (landers, rovers, orbiters...) delay is the only problem that can not be solved various deployed internet have to be connected by stable interplanetary gateways most of today s internet application can t be used in interplanetary internet, only SMTP after several modifications

7. Working conclusions IPN names should be represented in tupels IPN nodes will have to work as a store-and-forwardsystem for long-delay connections security has to be flexible and bandwidth-efficient long-haul transport protocol must be connectionless, so different from TCP deployed internets may use TCP, but other solutions are also possible