111,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Securing Delay-Tolerant Networks with BPSec One-stop reference on how to secure a Delay-Tolerant Network (DTN), written by experienced industry insiders Securing Delay-Tolerant Networks with BPSec answers the question, "How can delay-tolerant networks be secured when operating in environments that would otherwise break many of the common security approaches used on the terrestrial Internet today?" The text is composed of three sections: (1) security considerations for delay-tolerant networks, (2) the design, implementation, and customization of the BPSec protocol, and (3) how this protocol can be applied, combined with other security protocols, and deployed in emerging network environments. The text includes pragmatic considerations for deploying BPSec in both regular and delay-tolerant networks. It also features a tutorial on how to achieve several important security outcomes with a combination of security protocols, BPSec included. Overall, it covers best practices for common security functions, clearly showing designers how to prevent network architecture from being over-constrained by traditional security approaches. Written by the lead author and originator of the BPSec protocol specification, Securing Delay-Tolerant Networks (DTNs) with BPSec includes information on: * The gap between cryptography and network security, how security requirements constrain network architectures, and why we need something different * DTN stressing conditions, covering intermittent connectivity, congested paths, partitioned topologies, limited link state, and multiple administrative controls * Securing the terrestrial internet, involving a layered approach to security, the impact of protocol design on security services, and securing the internetworking and transport layers * A delay-tolerant security architecture, including desirable properties of a DTN secure protocol, fine-grained security services, and protocol augmentation Securing Delay-Tolerant Networks (DTNs) with BPSec is a one-stop reference on the subject for any professional operationally deploying BP who must use BPSec for its security, including software technical leads, software developers, space flight mission leaders, network operators, and technology and product development leaders in general.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 686
Veröffentlichungsjahr: 2022
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Dedication
Acronyms
About the Authors
Foreword
Preface
About the Companion Website
1 Introduction
1.1 A Pervasively Networked World
1.2 Motivation For This Book
1.3 Conventions
1.4 Organization
1.5 Summary
References
2 Network Design Considerations
2.1 Designing for Challenged Networks
2.2 Layered Network Architectures
2.3 Cryptography and Network Security
2.4 Summary
References
Notes
3 DTN Security Stressors and Strategies
3.1 DTN Constraints
3.2 Security-Stressing Conditions
3.3 Security Strategies
3.4 Summary
References
Notes
4 Delay-Tolerant Security Architecture Elements
4.1 Defining Security Architectures
4.2 IP Security Mechanisms
4.3 DTN Transport
4.4 A BPv7 Model for DTN Security
4.5 Scoping Bundle Security
4.6 Policy Considerations
4.7 Summary
References
Notes
5 The Design of the Bundle Protocol Security Extensions
5.1 A Brief History of Bundle Security
5.2 Design Principles
5.3 Determining Security Services
5.4 Protocol Comparisons
5.5 Summary
References
Notes
6 The BPSec Security Mechanism
6.1 The BPSec Mechanism
6.2 Security Operations
6.3 Security Contexts
6.4 Security Blocks
6.5 Block Integrity Block
6.6 Block Confidentiality Block
6.7 Other Security Blocks
6.8 Mapping
6.9 Summary
Reference
Notes
7 Security Block Processing
7.1 General Block Processing
7.2 The Extension Block Lifecycle
7.3 Security Operation Processing
7.4 Security Block Manipulation
7.5 Target Multiplicity Examples
7.6 Common Error Conditions
7.7 Summary
References
Notes
8 Security Dependency Management
8.1 Dependency Management
8.2 Bundle-Related Dependencies
8.3 Security-Related Dependencies
8.4 Dependency-Related Constraints
8.5 Special Processing Rules
8.6 Handling Policy Conflicts
8.7 Summary
References
Notes
9 Threat Considerations for BPv7 Networks
9.1 Security Implications of BPv7 Networks
9.2 Threat Model and BPSec Assumptions
9.3 Attacker Objectives and Capabilities
9.4 Passive Attacks
9.5 Active Attacks
9.6 Summary
References
10 Using Security Contexts
10.1 The Case for Contexts
10.2 Using Security Contexts
10.3 Summary
References
Notes
11 Security Context Design
11.1 Overview
11.2 Novelty
11.3 Network Considerations
11.4 Behavioral Considerations
11.5 Syntactic Considerations
11.6 Cryptographic Binding
11.7 Summary
References
Notes
12 Security Policy Overview
12.1 Overview
12.2 Policy Information Sources
12.3 Policy Information Types
12.4 Security Operation Events
12.5 Processing Actions
12.6 Matching Policy to Security Blocks
12.7 A Sample Policy Engine
12.8 Summary
References
Notes
13 Achieving Security Outcomes
13.1 Security Outcomes
13.2 Verifying BIB-Integrity
13.3 Verifying BCB-Confidentiality
13.4 Whole-Bundle Authentication
13.5 Protected Bundle Composition
13.6 Summary
Reference
Notes
14 Special Considerations
14.1 Scoping Security Concerns
14.2 BPA Resource Considerations
14.3 Bundle Fragmentation Considerations
14.4 Security Context Considerations
14.5 Policy Considerations
14.6 Summary
References
Notes
Appendix A: Example Security Contexts
A.1 Integrity Security Context
A.2 Confidentiality Security Context
References
Appendix B: Security Block Processing
B.1 Overview
B.2 Single-Target Single-Result Security Contexts
B.3 Single-Target Multiple-Result Security Contexts
B.4 Multiple Security Sources
Reference
Note
Appendix C: Bundle Protocol Data Representation
C.1 Bundle Protocol Data Objects
C.2 Data Representation
C.3 CDDL Representations
References
Note
Index
End User License Agreement
List of Tables
Chapter 2
Table 2.1 Sources of constraint types.
Chapter 4
Table 4.1 BP features enable security strategies.
Chapter 5
Table 5.1 Handling dual integrity signatures.
Table 5.2 BPSec design flows from lessons learned.
Table 5.3 BPSec services implement some, but not all, security capabilities....
Table 5.4 BPSec borrowed features.
Chapter 6
Table 6.1 BPSec security service and target uniqueness.
Table 6.2 BPSec mechanism components fulfill design principles.
Chapter 7
Table 7.1 Target multiplicity results in significant size savings.
Chapter 8
Table 8.1 BPSec security element dependencies types.
Chapter 9
Table 9.1 Attacks defined by RFC 3552.
Chapter 10
Table 10.1 Pre-Shared Key cipher suites with NULL encryption for transport l...
Chapter 11
Table 11.1 Security context target associations.
Chapter 12
Table 12.1 Actionable block processing control flags.
Table 12.2 Security Operation Events and Associated Processing Actions.
Appendix A
Table A.1 Parameters for BIB-HMAC-SHA2.
Table A.2 SHA variant parameter values.
Table A.3 Integrity scope flag values.
Table A.4 BIB-HMAC-SHA2 security results, from RFC 9173.
Table A.5 Parameters for BCB-AES-GCM.
Table A.6 Parameter values for the optional AES variant parameter.
Table A.7 Bit field definitions of the AAD scope flags parameter.
Table A.8 BCB-AES-GCM security results.
Appendix C
Table C.1 Occurrence indicators are used to build array a from predefined gr...
List of Illustrations
Chapter 1
Figure 1.1 Internet usage is growing (unevenly) worldwide. The adoption ...
Figure 1.2 Digital media is predominantly access via mobile devices.
Figure 1.3 DTN protocols federate vastly disparate networks.
Figure 1.4 Common network threats and protection.
Chapter 2
Figure 2.1 Tooling generates interoperability requirements. Network CONOPS a...
Figure 2.2 Network devices implement different networking stacks. Nodes repr...
Figure 2.3 Encapsulation hides information from other network layers.
Figure 2.4 Disruption prevents end-to-end message exchange. (a) End-to-end c...
Figure 2.5 Delay can only be assessed relative to some performance requireme...
Figure 2.6 Cipher suites support both internal and external configurations....
Figure 2.7 Network security protocols package cryptographic materials. The g...
Chapter 3
Figure 3.1 The complexities of interplanetary networking exemplify the secur...
Figure 3.2 Techniques for secret establishment. There is a relationship betw...
Figure 3.3 A network topology evolves over time. A given mobile node (N) may...
Figure 3.4 Tunnels should not be tied to topology. Tunnels endpoints must re...
Figure 3.5 Highly cohesive, loosely coupled architectures increase reuse. De...
Figure 3.6 Keys lose their effectiveness with use and over time. Keys on nod...
Chapter 4
Figure 4.1 IP represents a common element of many networking stacks. The met...
Figure 4.2 IPSec encryption adds special headers to denote security services...
Figure 4.3 The BPv7 bundle format. Bundles are modeled as a collection of bl...
Figure 4.4 Bundles flow over multiple transport and network layers. Transpor...
Figure 4.5 A single bundle can carry multiple sets of secured information. W...
Figure 4.6 BPSec enables security diversity within a bundle. Different secur...
Figure 4.7 Configuration information may come from multiple sources to a BPA...
Chapter 5
Figure 5.1 Bundle security cannot be tied to routing. The time-variant topol...
Figure 5.2 Redundant signatures over a block lead to processing ambiguity. I...
Figure 5.3 Multiple encryption requires ordered decryption. When nodes encry...
Figure 5.4 Bundles can carry a variety of data. BPAs may add node, path, and...
Figure 5.5 Multiple security sources coexist within a single bundle. A BPA r...
Figure 5.6 Security processing is driven by local security policy. A BPA mig...
Figure 5.7 BPSec provides fine-grained integrity checking for blocks. By fin...
Chapter 6
Figure 6.1 Security operations in a bundle must remain unique. Security oper...
Figure 6.2 Security contexts provide behavior in addition to cryptographic p...
Figure 6.3 Merging Security Blocks. A BPA should merge security blocks whene...
Figure 6.4 The Abstract Security Block. All security blocks share the same b...
Figure 6.5 Security block results are organized by target block. Each target...
Figure 6.6 A BIB block is populated from the security context and local conf...
Figure 6.7 Block flags impact processing. Setting block processing control f...
Figure 6.8 A BCB block replaces the plaintext of its target block with ciphe...
Figure 6.9 BCBs may be replicated in every bundle fragment. BCB blocks shoul...
Figure 6.10 Disallowed BCB operations. The three security operations carried...
Figure 6.11 BPSec allows for the definition of other security blocks. BPSec ...
Chapter 7
Figure 7.1 BPAs process extension blocks in two ways. Every BPA first examin...
Figure 7.2 A generic extension block processing lifecycle. All extension blo...
Figure 7.3 Block processing may occur in multiple ways. Transcoding every bl...
Figure 7.4 Security policy roles. Local policy identifies security source ➀,...
Figure 7.5 Target Multiplicity Reduces Bundle Footprint. Target multiplicity...
Figure 7.6 Merging security blocks. When the security operations in two bloc...
Figure 7.7 Security operations can be removed from a security block. Operati...
Figure 7.8 Target Multiplicity for Confidentiality.
Figure 7.9 Target Multiplicity for Block Integrity.
Chapter 8
Figure 8.1 BPv7 bundles exhibit both information and structure dependencies.
Figure 8.2 Inter-bundle dependencies impact bundle delivery. The inability o...
Figure 8.3 Security operations and blocks have different dependencies. Encry...
Figure 8.4 Policy configurations determine security roles. Security blocks d...
Figure 8.5 BPSec requires inclusive confidentiality. Only encrypting the tar...
Figure 8.6 Block policy and security policy can conflict. A BPA receives a b...
Figure 8.7 Prioritizing security policy over block policy. Processing securi...
Figure 8.8 Prioritizing block policy over security policy. Reviewing block p...
Figure 8.9 A time-based view of block processing. The processing of a secure...
Chapter 9
Figure 9.1 IKEv2 messaging. Establishment of an IKEv2 security association r...
Figure 9.2 Vulnerabilities exist end-to-end in a network. Federating multipl...
Figure 9.3 Topology impacts attackers capabilities. A sample network shows c...
Figure 9.4 Traffic profiling can reveal network data. An OPA can infer netwo...
Figure 9.5 Queuing traffic impedes profiling. The store-and-forward nature o...
Figure 9.6 Injected bundles include both new and old bundles. An On-Path Att...
Figure 9.7 Topology attacks influence routing. Attackers can influence the r...
Chapter 10
Figure 10.1 Security contexts evolve over time. Future block types might use...
Figure 10.2 Cipher suite inputs and outputs. The terms cleartext and ciphert...
Figure 10.3 Security contexts interface BPSec to cipher suites. Security con...
Figure 10.4 Not all BPAs support the same security contexts. While every BPA...
Figure 10.5 Initial BPSec Security Context Definitions. The initial set of s...
Figure 10.6 Security contexts can follow network topology. BPSec does not en...
Figure 10.7 Security contexts fuse parameters from multiple sources. Securit...
Figure 10.8 Multiple results provide security resiliency. Security services ...
Chapter 11
Figure 11.1 Parameterization reduces duplication. (a) Failing to parameteriz...
Figure 11.2 Single-Target, Single-Result Security Contexts. STSR security co...
Figure 11.3 Single-Target, Multiple-Result Security Contexts. STMR security ...
Figure 11.4 BPSec blocks CANNOT be used for multiple-target associations. At...
Figure 11.5 Monolithic data sets construct a single security result. Multipl...
Figure 11.6 Independent data sets build multiple security results. Multiple ...
Chapter 12
Figure 12.1 Policy information comes from multiple sources. Ready access to ...
Figure 12.2 The security operation lifecycle. The security operation lifecyc...
Figure 12.3 Remove lone security operation. If a security block has a single...
Figure 12.4 Remove one of many security operations. In cases where a securit...
Figure 12.5 Removing security target blocks. When removing a target block fr...
Figure 12.6 Removing security operations based on target block. Issues with ...
Figure 12.7 A sample mapping of security policy structures and their interac...
Figure 12.8 Security operation events map to multiple processing actions. Se...
Chapter 13
Figure 13.1 In-network integrity verification.
Figure 13.2 Verifying confidentiality. Confidentiality services can be verif...
Figure 13.3 In-Network confidentiality verification.
Figure 13.4 Whole-bundle integrity can be implemented as multi-block integri...
Figure 13.5 Two ways to capture whole-bundle authentication. Whole-bundle au...
Figure 13.6 Block and bundle relationships. Not every block in a bundle has ...
Figure 13.7 Harmful bundle manipulations. Any manipulation of a bundle that ...
Figure 13.8 Source and destination criticality. Identifying critical and sup...
Figure 13.9 In-Band policies are implemented with extension blocks. The in-b...
Chapter 14
Figure 14.1 Differing levels of inspection. Bundle inspection produces stand...
Figure 14.2 Fragmentation delays security processing. Services such as integ...
Figure 14.3 Replicating security blocks can lead to confusion. If security b...
Figure 14.4 Bundle retransmission causes uneven key use for a single securit...
Figure 14.5 Key expiration must be considered for long lived bundles. Assumi...
Figure 14.6 Manipulating bound blocks can prevent security processing. If an...
Figure 14.7 Multiple security acceptors. Having multiple security acceptors ...
Figure 14.8 Security contexts must match their security usage. A BPA configu...
Figure 14.9 Security policies using EIDs. Policies that use EIDs must be awa...
Figure 14.10 Rule Collisions. Nesting rule statements from general to specif...
Appendix A
Figure A.1 Unsecured Integrity Scope Flags lead to security vulnerabilities.
Figure A.2 Input canonicalization of IPPT. This shows the ordering of the ca...
Figure A.3 Input Canonicalization of AAD. This shows the ordering of the can...
Appendix B
Figure B.1 Single-target single-result confidentiality.
Figure B.2 Single-target single-result integrity.
Figure B.3 Single-Target Multiple-Result Confidentiality.
Figure B.4 Single-Target Multiple-Result Integrity.
Figure B.5 Multiple Security Sources Create Tunnels.
Figure B.6 Multiple Security Contexts Provide Different Security Services.
Appendix C
Figure C.1 Block definitions and relationships. BPSec-related blocks are def...
Figure C.2 CBOR Text Encoding. This is an example from RFC 8949 of the encod...
Guide
Cover
Title Page
Copyright
Dedication
Acronyms
About the Authors
Foreword
Preface
About the Companion Website
Table of Contents
Begin Reading
Appendix A: Example Security Contexts
Appendix B: Security Block Processing
Appendix C: Bundle Protocol Data Representation
Index
End User License Agreement
Pages
iii
iv
v
xix
xx
xxi
xxiii
xxiv
xxv
xxvi
xxvii
xxix
xxxi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
Securing Delay-Tolerant Networks with BPSec
Dr Edward J. Birrane III, Sarah Heiner, and Ken McKeever
This edition first published 2023© 2023 John Wiley & Sons, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Dr Edward J. Birrane III, Sarah Heiner, and Ken McKeever to be identified as the authors of this work has been asserted in accordance with law.
Registered OfficeJohn Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of WarrantyIn view of ongoing research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
Library of Congress Cataloging-in-Publication Data Applied for:ISBN: 9781119823476 (hardback)
Cover Design: WileyCover Image: © Sergey Panychev/Shutterstock
This book is dedicated to the memory of Ralph E. Piersanti – educator, athlete, actor, friend, and (for large parts of my childhood) an eminently convincing Batman.
Dr Edward J. Birrane III
This book is dedicated to my family. Thank you for seeing, and being, the magic.
Sarah Heiner
This book is dedicated to Gillian McKeever, for her support, patience, and most of all understanding of the multitude of endeavors (like this one) that seem to keep me otherwise busier than I should rightly be.
Ken McKeever
Acronyms
AAD
Additional Authenticated Data
ABE
Attribute-Based Encryption
AEAD
Authenticated Encryption with Associated Data
AES
Advanced Encryption Standard
AH
Authentication Header
API
Application Programming Interface
ARPAnet
Advanced Research Projects Agency Network
ASB
Abstract Security Block
BAB
Bundle Authentication Block
BCB
Block Confidentiality Block
BIB
Block Integrity Block
BPA
Bundle Protocol Agent
BPCF
Block Processing Control Flags
BPSec
Bundle Protocol Security
BP
Bundle Protocol
BPv6
Bundle Protocol version 6
BPv7
Bundle Protocol version 7
BSP
Bundle Security Protocol
CA
Certificate Authority
CBOR
Concise Binary Object Representation
CCSDS
Consultative Committee for Space Data Systems
CDDL
Concise Data Definition Language
CIA
Confidentiality, Integrity, and Availability
CLA
Convergence-Layer Adapter
CMS
Cryptographic Message Syntax
CONOPS
Concept of Operations
COSE
CBOR Object Signing and Encrypting
COVID-19
Coronavirus Disease 2019
CRC
Cyclic Redundancy Check
DES
Data Encryption Standard
DNSSEC
Domain Name System Security Extensions
DTLS
Datagram Transport Layer Security
DTN
Delay Tolerant Networking
ECDHE
Elliptic Curve Diffie–Hellman Exchange
EID
Endpoint Identifier
ESB
Extension Security Block
ESP
Encapsulating Security Payload
FTP
File Transfer Protocol
GCM
Galois Counter Mode
GPS
Global Positioning System
HMAC
Hashed Message Authentication Code
HTTPS
Hypertext Transfer Protocol Secure
IANA
Internet Assigned Numbers Authority
ID
Identifier
IETF
Internet Engineering Task Force
IKE
Internet Key Exchange
ION
Interplanetary Overlay Network
IPN
Interplanetary Network
IPSec
Internet Protocol Security
IP
Internet Protocol
IPPT
Integrity-Protected Plaintext
IRTF
Internet Research Task Force
ISP
Internet Service Provider
IV
Initialization Vector
JPL
Jet Propulsion Laboratory
JSON
JavaScript Object Notation
LAN
Local Area Network
LTP
Licklider Transport Protocol
MAC
Message Authentication Code
MET
Mission Elapsed Time
MILnet
Military Network
MTMR
Multiple-Target Multiple-Result
MTSR
Multiple-Target Single-Result
MTU
Maximum Transmission Unit
NASA
National Aeronautics and Space Administration
NCP
Network Control Program
NIST
National Institute of Standards and Technology
NPA
Near-Path Attacker
NP
Network-layer Protocol
NSFnet
National Science Foundation Network
NTP
Network Time Protocol
OPA
On-Path Attacker
OP
Operation
OpenSSL
Open Secure Socket Layer
OSB
Other Security Block
PCB
Payload Confidentiality Block
PDU
Protocol Data Unit
PIB
Payload Integrity Block
PKI
Public Key Infrastructure
PNB
Previous Node Block
PSK
Pre-Shared Key
RAM
Random Access Memory
RC4
Rivest Cipher 4
RFC
Request for Comments
RSA
Rivest-Shamir–Adleman
SBSP
Streamlined Bundle Security Protocol
SCPS
Space Communications Protocol Suite
SHA
Secure Hash Algorithm
SOp
Security Operation
SSI
Solar System Internet
SSL
Secure Socket Layer
STMR
Single-Target Multiple-Result
STSR
Single-Target Single-Result
TCP
Transmission Control Protocol
TC
Telecommand
TLS
Transport Layer Security
TM
Telemetry
TTP
Trusted Third Parties
UDP
User Datagram Protocol
URI
Uniform Resource Identifier
UTC
Coordinated Universal Time
VPN
Virtual Private Network
WLAN
Wireless Local Area Network
WoT
Web of Trust
About the Authors
Dr Edward J. Birrane III
Dr Birrane is a computer scientist and embedded software engineer who focuses on the adaption of computer networking protocols for use in non-traditional environments. He has supported a variety of embedded software engineering efforts, to include the NASA New Horizons mission to explore the Pluto-Charon system and the NASA Parker Solar Probe mission to observe the outer corona of our sun.
He works with industry, government, and academia on the design and development of protocols to implement the Delay-Tolerant Networking (DTN) architecture. He co-chairs the DTN working group within the Internet Engineering Task Force (IETF) where he is a coauthor of BPv7 (RFC 9171), BPSec (RFC 9172), and the default security contexts for BPSec (RFC 9173). He is a member of the principal professional staff at the Johns Hopkins University Applied Physics Laboratory as the Chief Engineer for Space Constellation Networking. He is also an adjunct professor of computer science at both the University of Maryland, Baltimore County, and The Johns Hopkins University.
Sarah Heiner
Sarah Heiner is part of a passionate community of inventors working on a set of emerging networking protocols. She has contributed to the body of DTN work in several areas, with a primary focus on Bundle Protocol Security (BPSec). Involved with both the Internet Engineering Task Force and the Consultative Committee for Space Data Systems, Sarah is a coauthor of RFC 9173 BPSec Default Security Contexts, the Bundle Protocol Security Protocol Red Book, and the Asynchronous Management Architecture, among other documents. She received a bachelor's degree in computer science from the University of Maryland, Baltimore County, and is currently pursuing a master's degree in computer science at The Johns Hopkins University Applied Physics Laboratory.
Ken McKeever
Despite early aspirations of a career as a mad scientist, Ken McKeever is now a communication systems engineer and researcher. He received a bachelor's degree in electrical engineering from the Pennsylvania State University and a master's degree in electrical and computer engineering at The Johns Hopkins University Applied Physics Laboratory. His current focus is on the design of resilient networked communication systems operating in constrained environments and is the coauthor of BPSec (RFC 9172). His other research interests include wired and wireless communications security, protocol design, and test and evaluation of communication systems.
Foreword
I have been involved with computer and network security since 1975 after I received my undergraduate degree in electrical and computer engineering. Back then computer security was a fledgling profession primarily concerned with processing data of multiple classification levels simultaneously (i.e. multilevel security). Likewise, network security, in the ARPAnet days with the few attached computer systems running the Network Control Program (NCP) prior to the deployment of TCP/IP, was primarily concerned with the ability to ensure data confidentiality from sender to receiver. As the ARPAnet begat the MILnet which in turn begat the NSFnet and TCP/IP replaced NCP, the worldwide Internet explosion took place and networking evolved to what we know it to be today. I became involved with security for space with an early effort to use Internet protocols (e.g. TCP, IP, FTP) for space missions. An outgrowth of the Internet Protocols (IPs) in space was the Interplanetary Internet (IPN) and what we now know as the Bundle Protocol (BP) and its associated Bundle Protocol Security (BPSec). As one of the most exciting projects in my career, I worked on the Jet Propulsion Laboratory (JPL) team that architected the IPN/DTN and specifically, the security architecture and the security protocol.
In the early 1990s, while the Internet was beginning its world-wide growth using a standard protocol stack, the space communications community was still using decades old link layer protocol standards such as Telemetry (TM), and Telecommand (TC). When upper layer protocols were needed for space missions, there were no standards, and protocols would be (re)invented for each mission. This was costly, time consuming, and inefficient.
With the success of the Internet's Transmission Control Protocol/Internet Protocol (TCP/IP) standards, the thought at the JPL was why not adapt those protocols for use in space missions. The result was a series of protocols known as the Space Communications Protocols Suite (SCPS) which consisted of a space-specific network layer protocol (NP), a transport protocol (TP) which was an adaptation of TCP for use in long delay-bandwidth environments, a space-specific “thin” security protocol (SP), and an adaptation of the Internet file transfer protocol (FP). Even in the 1990s we knew that security had to be included in the protocol stack from the get-go.
It was determined that the SCPS protocols would be excellent upper layer protocols for space missions in near-earth orbit and maybe even at lunar distances. However, there were too many issues which prevented SCPS protocols to work beyond lunar distances.
NASA's next bold adventure was the unmanned exploration of Mars. It was anticipated that a large array of Mars orbiters, landers, and rovers would be launched to Mars over the decades. Landers and rovers might have direct-to-earth links, but more than likely they would make use of orbiting relays to minimize the size and weight of the landers. To the networking community, this looked like the beginnings of a network at Mars – both space-based around Mars and surface-based on Mars.
We knew that the SCPS protocols would work on the surface of Mars and near Mars but that between Earth and Mars, we needed an entirely new networking paradigm. It had to support orbital mechanic obscuration, loss of connectivity, long delays, ability to operate through relays, and it needed to be secure.
As a result, the IPN was “born.” The intent was to design a set of protocols that could provide secure Internet-like services at long distances, while plagued with intermittent connectivity and the inherent bandwidth delays. As with SCPS, security was baked in from the outset. Too often, security is an afterthought (if at all considered) and then “bolted on” resulting in spectacular security failures. We decided that we were not going to go down that road once again. Over time, the IPN morphed to become the Delay Tolerant Internet and the Disruption Tolerant Internet (DTN). While the original vision was a secure network paradigm for deep-space networking, other non-space networking communities realized that the same architecture could be used to enable their needs. This included terrestrial sensor networks and battlefield networks – both suffering from intermittent connectivity resulting in long delivery delays under which TCP would not operate efficiently. DTN could also provide an architectural solution for other resource constrained environments, i.e. Internet connectivity in rural locations over narrow bandwidth and long-delay connectivity.
For deep space, it was believed that the IPN/DTN would have a finite (i.e. small) amount of bandwidth available and therefore it was of paramount need to assure that only those who needed access were provided with the ability to use the network (i.e. access control). Likewise, data integrity/authentication and data confidentiality were paramount DTN security requirements. Like space, non-space environments might also suffer from intermittent connectivity, narrow bandwidths, and long delivery delays.
The BP is the fundamental DTN protocol. BP provides the means to efficiently transport data across an intermittently connected network with widely differing bandwidth links. While TCP was designed to operate in fully connected, low-delay environments, BP was designed to operate in intermittently connected, long delay environments. However, BP does not address the DTN security requirements, nor should it. Rather, in a layered approach, a separate security protocol was developed. Akin to the Internet Protocol Security (IPSec) Protocol providing security for the IP, the Bundle Security Protocol (BSP) was designed to provide standard mechanisms to provide integrity, authentication, and confidentiality services for BP.
As is the case with IPSec, the BSP security services are optional to use. However, users determined that the original version of BSP was a complicated protocol to implement and even more so, complicated to ensure its security. As a result, a “streamlined” version of the Bundle Security Protocol was developed appropriately called the Streamlined Bundle Security Protocol (SBSP). SBSP was “lighter” and “simpler” than its BSP predecessor. SBSP was paired as the security protocol through Bundle Protocol version 6 (BPv6). But with major changes between BPv6 and BPv7, yet another set of changes resulted in the evolvement to a newer version of the bundle security protocol which we now know as BPSec. This book will provide the technical details of BPSec, its layering on BP, its security services and mechanisms, and how it enables a secure DTN architecture.
While the protocols to implement a secure Delay Tolerant Network now exist, there are still many security issues that need to be researched and solved. Among them are security management and the associated cryptographic key management. The Internet, with its fully connected and short delay connectivity can use asymmetric key agreement and certificate authorities. However, in resource constrained environments and intermittently connected environments, asymmetric key agreement may not work. In small networks, traditional pre-placed cached key material might suffice but will not scale with network growth. These constraints will probably result in the need for multiple standards to support the various DTN environments. More work is still needed to arrive at a set of security management standards. But while more research and work remain, the basis of DTN security has been developed and is ready for use to provide secure services now.
We've come a long way from the days of TM and TC providing point-to-point ground-to-space connectivity. We now have networks on the ground and in space, with many more to come both on Earth and interplanetary. The secure DTN architecture has provided the network technology to enable the design, implementation, and secure operation of those future interplanetary networks.
Howard Weiss
Parsons, Inc.
Principal Project Manager
Preface
A preface must answer (at least) important question:
What should I be learning from this book?
Lurking in that query are existential questions about the nature of the book and, at times, the nature of the reader. So let me answer that question – the question – as straightforwardly as I can.
Over the next hundreds of pages, of course, you will find technical details of how to apply a particular kind of security to a particular kind of networking environment. You will see details about why design decisions were made and the implications of all of this on the architects, engineers, and operators making real networks work.
This book is meant to be a little more than just all that.
Allow me to make an observation about the nature of new ideas: sometimes the difference between a very big idea and a very small idea is the person looking at that idea.
When creating the Bundle Protocol, version 7 (BPv7) there were two very small ideas – expressive headers and stored messages. Yetin the right hands they became very big ideas about connecting our planet and our solar system. Similarly, BPSec has a small idea – secure message parts individually. Yetin your hands that can become a very big idea about secure networks.
A long-established tradition in the education of computer scientists and software engineers is to periodically repeat the phrase “include security from the start.” It makes good sense and there are certainly cautionary tales involving applying security too late. Mostly, this adage is hard to translate into preventative action. What does it mean to “include security” and at the start of what?
BPv7 and BPSec are a chance to build security into the foundations of our messaging from that first byte of header to that last bit of payload. This very small idea might grow into very big ideas about the tools and techniques we use to build networks. About rethinking encapsulation. About securing data at rest. That very small idea could change what we think of when we say include security from the start.
Therein lies the challenge to the reader and the thing you should learn from this book. Do not just understand the technical implementation of these small ideas; uncover and discover the big ideas hiding right behind them.
So, enjoy this book with an open mind and a creative imagination.
And happy hunting.
Dr Edward J. Birrane III
About the Companion Website
This book is accompanied by a companion website:
www.wiley.com/go/birrane/securingdelay-tolerantnetworks
This website material contains the CCDL code and its notes as software resources.
1Introduction
Delay-Tolerant Networking (DTN) refers to both a networking architecture and a set of protocols and practices used to instantiate that architecture. One unique characteristic of this architecture is that it combines the concepts of store-and-forward and network overlay to federate otherwise disparate networks. In doing so, the DTN architecture provides resilience to challenging conditions that would break more commonplace network architectures.
This chapter discusses the design, implementation, and configuration of security for stressed networking environments using the protocols and extensions built to secure the DTN environment. This discussion includes the rationale for the DTN architecture, how solutions to that architecture can apply to other stressed environments, and why securing this architecture requires new security mechanisms.
This chapter provides three different but equally important introductions to this material.
Why a DTN Architecture
: Expectations for what a computer network should do, and the way in which it should operate, stem from experiences with existing networks. There is a growing desire to more pervasively instrument, monitor, and interact with our environment – both on and off planet Earth. Doing so requires expanding our concept of what a computer network is and how it should operate.
What Motivated This Book
: This book is written to answer questions relating to the design, implementation, and anticipated usage of DTN security mechanisms. This includes observations on the challenges inherent in a DTN environment and the unique capabilities of DTN transport protocols.
Where is Information Located
: The content of this book is structured to enable rapid referencing of materials as a function of the role of the reader. Early material discusses aspects related to DTN network security, middle material explains existing protocol capabilities and behaviors, and later materials explain how to combine and configure these protocols in unique networking deployments.
1.1 A Pervasively Networked World
The scientific, social, and commercial benefits of easy access to communication services are apparent to anyone who has used the Internet since the turn of the century. Since its inception in the 1980s, the Internet has continued to grow in number of users, data transport speeds, and overall amount of data communicated. Recent increases in Internet use is driven by increases in user communities (to include social media), larger data volumes (to include higher resolution multimedia), and the rise of machine-to-machine connections.
Figure 1.1Internet usage is growing (unevenly) worldwide.
Source: International Telecommunication Union/OurWorld in Data/CC BY 4.0.
The adoption of Internet usage is growing, albeit unevenly, worldwide. This shows both the existing scale, and therefore the future work, needed to complete the instrumentation of our world.
Consider the share of the population accessing the Internet, illustrated in Figure 1.1. This listing of selected regions shows three clusters of use and adoption: rapid adoption, fast-following, and emerging. Data such as these show both the tremendous scale of the existing Internet and the tremendous growth remaining before usage is truly saturated.
Coincident with the increase in Internet users, access methods for the network are diversifying. Figure 1.2 shows, within the United States during the data reporting period, the rise in mobile access to the Internet to dominate the number of hours users spend producing and consuming network data.
In well-resourced environments, the Internet continues to demonstrate reliability and resilience, even in the presence of significantly different types of traffic utilization. A particularly motivating analysis of the behavior of the network in abnormal conditions can be performed on 2020 trends associated with the COVID 19 pandemic.
Through the pandemic, intuition would suggest growth in Internet usage driven by more access to entertainment, video conferencing, and less in-person communication. Initial analyses indicate that, as expected, network usage was increased during the pandemic, although this increase did not have the expected magnitude. Internet usage grew by approximately 15% with a more modest 5% increase in peak traffic volumes [1]. Specific applications (such as video teleconferencing) did experience higher increases in traffic usage, but this was offset by reductions in the use of other applications.
Person-to-person communication is the most recognized use of the Internet. However, this type of communication no longer represents the bulk of network traffic. This is why changes in how people use the Internet, such as during a pandemic, did not have the same impact on peak network traffic as intuition would otherwise imply.
Figure 1.2Digital media is predominantly access via mobile devices.
Source: OurWorldInData.org/internet.
In particular, machine-to-machine connections are growing with the number of online devices. The use of the Internet for machine-to-machine communications – termed the Internet of Things (IoT) – is becoming the dominant source of networking traffic. It is estimated that upwards of a trillion such devices will be online by 2035 [2]. See Focus: The Internet of Not People on next page.
The rise of IoT as a source of network traffic has implications beyond just the need to increase data speeds and data throughput. IoT represents the aspiration of extending the instrumentation and observation of our environment to increasingly remote locations on Earth, in near-space, and across our solar system. As exemplified by the extreme case of deep-space robotic spacecraft, networked devices can be placed in environments where humans cannot go.
The desire to collect information about remote parts of planet Earth and the solar system is outpacing the ability to densely populate these areas with resources. Adapting the Internet model to very challenged environments requires building an extensive infrastructure that cost of which rapidly reaches a point of diminishing returns.
Rather than making the solar system look like a densely populated city, new networking algorithms and protocols are being developed to operate in areas that have less access to, and less reliance on, a dedicated communications infrastructure.
Social networking, telerobotics, telemedicine, distance learning, and even self-driving cars are examples of how more and more rapid communications change everyday aspects of our lives…[t]o sustain the rate of progress in this area, new approaches must be adopted, such as … highly mobile network nodes to provide coverage in challenged environments.
The Path to Space-Terrestrial Internetworking [4]
Focus: The Internet of Not People
Bios Robotlab Writing Robot.
Source: [3], Mirko Tobias Schaefer, Wikimedia Commons, CC BY 2.0.
The IoT refers to the growing segment of Internet use for machine-to-machine communication, such as sensor data transfer, notifications, and machine health and status information.
IoT communications benefit from more reliability and lower latency than human-in-the-loop communications. This is because devices can process data faster than humans but cannot intelligently adapt to abnormal circumstances.
Further attempts to distinguish traffic patterns have led to derivative notations such as the “Internet of Moving Things” to represent vehicular networks and the “Internet of Space” to represent space-terrestrial internetworks.
1.1.1 A New Networking Approach
DTN protocols represent a standardized approach to store-and-forward data distribution when timely, end-to-end connectivity cannot be guaranteed. These protocols were originally developed to enable deep-space, packetized networks impacted by long signal propagation delays and link disruptions.
DTN approaches also provide benefits for nearer-to-Earth networks that might experience disruptions resulting in a delay of messages from a sender to a receiver. These disruptions come from both physical issues (such as available transmitter power or antenna pointing) as well as logical issues (such as administrative permissions and traffic prioritization schemes).
Near-Earth spacecraft constellations, “IoT” networks, undersea networks, and vastly distributed sensing systems all experience these physical and logical disruptions. Across these environments, and more, DTN protocols can be used to build federated networks unlike any built before.
Figure 1.3 illustrates this concept of federating vastly disparate networks that cross environments with extreme communications challenges. Constructs like this cannot reasonably require that all devices stay in persistent, powered, timely contact with a centrally organized and managed network.
Figure 1.3DTN protocols federate vastly disparate networks.
Source: Forrest Warthman and NASA.
The beneficial use cases for building these challenged networks are many. They can better the understanding and utilization of our planet by allowing sensor placement in increasingly remote and challenges areas of the world. They enable more ubiquitous and cost-effective telecommunications by relaxing real-time bandwidth requirements on networks for non-real-time data. They can provide graceful network degradation and more rapid network healing in times of disaster and war [4].
1.1.2 A New Transport Mechanism
NASA, in coordination with other space agencies, industry, and academia, has standardized the Bundle Protocol (BPv7) [5] as an alternative to the Internet Protocol (IP) in cases where networks are challenged by significant signal propagation delays or frequent link disruptions.
BPv7 agents implement store-and-forward behaviors and the BPv7 protocol data unit, the bundle, is designed to carry end-to-end session information and other annotations. By carrying additional information, bundles can be processed by challenged network nodes that cannot independently maintain end-to-end session state.
As is the case with many networking protocols, BPv7 should be expected to operate in deployments where network nodes (and the links amongst them) cannot always be trusted. BPv7 is not, inherently, secure. Just like the Transmission Control Protocol (TCP) and IP protocols prevalent on the Internet, BPv7 must operate within a security ecosystem to ensure proper delivery of bundles.
Figure 1.4 illustrates some of the security protections used over the Internet to provide a secure ecosystem for the exchange of TCP and IP messages. Individual protections, their configuration, and best practices for their use will evolve over time as capabilities and threats evolve. The value of this view of network security is that it showcases how multiple elements must work together to enable security.
Figure 1.4Common network threats and protection.
Source: [6], Andrzej Kasprzyk, Wikimedia Commons, CC BY 3.0.
The potentially stressed nature of a BPv7 operating environment imposes unique conditions where usual security mechanisms may not be sufficient. For example, the store-carry-forward nature of the network may require protecting data at rest, preventing unauthorized consumption of critical resources such as storage space, and operating without regular contact with a centralized security oracle (such as a certificate authority). An end-to-end security service is needed that operates in all the environments where BPv7 operates.
Securing Challenged Networks
The deployment of BPv7 leads to a fundamental question: how can we secure store-and-forward networks? How can we secure BPv7 bundles?
1.1.3 A New Security Mechanism
Security protocols used to secure the transport layer, the network layer, or both must operate within the set of policies, assumptions, constraints, and performance requirements of the networks in which they operate.
For example, the set of security protocols used over the Internet may differ from similar protocols used within cellular networks, near-Earth or deep-space spacecraft constellations, and very resource-constrained IoT devices. In some cases, these deployments may utilize similar algorithms for generating and processing cryptographic materials and only differ in how these algorithms are configured and applied. In other cases, new algorithms may need to be created to properly function.
Because BPv7 may operate in any one of a myriad of challenged networking domains, the security of bundles might not be able to reuse the familiar transport and network security mechanisms used on the Internet today. For example, the capabilities illustrated in Figure 1.4 might not be applicable to spacecraft constellations or sensors deployed in remote areas.
BPSec
The BPSec specification uses BPv7 features to secure BPv7 bundles.
Security ecosystems will continue to develop and mature to adapt to the characteristics of new deployment scenarios. To the extent that a network conveys BPv7 bundles, a security mechanism built specifically for BPv7 must be a part of that security ecosystem. The Bundle Protocol Security (BPSec) specification defines a set of security features built specifically to secure BPv7 bundles using unique BPv7 features.
1.2 Motivation For This Book
The motivation for this book is to answer questions related to DTN architectures and how they might effectively be secured. Some of these questions address how existing elements, such as emerging protocols, should be used to achieve security results. Others address how these networks should be architected for (and policies built around) emerging protocols.
Specifically, this book answers the following questions.
Can challenged networks effectively be secured? Network designers and application programmers cannot download and use traditional security packages (as-is) in challenged networks. However, this does not mean that network layer security is impossible in stressed environments. This book discusses the mechanisms available to secure even the most disrupted networks.
How can I make my security infrastructure more resilient to attacks? Operational networks often reduce their security posture if the performance of the network degraded. This invites malicious perturbation of network communications as a common network attack. If the performance of the network can be degraded enough that less security is applied (or verified at each hop) then the overall security posture of the network is reduced. Network engineers and application developers must consider ways of operating securely in degraded scenarios rather than waiting out periods of instability. This book describes the separation of cryptographic materials and the protocols that carry that material and how this distinction can be used to increase the resilience of security protocols when networks become degraded.
How can I prevent my network architecture from being over-constrained by traditional security approaches? Network security engineering often starts by building networks that can support the assumptions/requirements of traditional security protocols. When adopting security protocols from a well-resourced environment into a less-resourced environment, network engineers would need to over-engineer a challenged network deployment, making it more expensive to build and operate. Some environments are so challenged there is no way to over-engineer the network to make it behave like the Internet. This book demonstrates how networks can be architected differently if a delay-tolerant security approach is adopted, because such an approach places fewer assumptions/requirements on the networking layer.
Can DTN security continue to protect data when it is not actively in the network? Network designers and application developers typically differentiate data security within a network and the security of the data when it is no longer in the network. The DTN architecture blurs these boundaries by allowing data to be stored on nodes that are not the destination of the data. This book discusses how the security of data-at-rest can be achieved using BPSec without the need for application-specific mechanisms.
1.3 Conventions
There are a few conventions employed throughout this book to bring special attention to information. Understanding what mechanisms are used to highlight what information is helpful in understanding how to quickly find and review information.
1.3.1 Focus Studies
Focus studies refer to a relatively short, focused set of information providing some context for an expressed point of view. These focuses are offset from the main book text to call attention to them, usually with the addition of a representative illustration.
Focus: The Use of Focus Studies
Source: Marek/Pexels.
Where helpful, focus studies call special attention to ideas, concepts, or examples helpful to understanding the context, implementation, or benefits of some element of DTN security. While this book presumes basic knowledge of networking concepts, some experiences or technologies have been more influential in the design of DTN solutions than others.
These studies can highlight subtle connections between DTN features and existing capabilities. In doing so, they provide hints for further reading or otherwise help to frame the context for the DTN conversation.
1.3.2 Summary Boxes
Many of the security concepts discussed in this book are derived as a series of evolutions starting with observations of an existing capability and progressing through logical modifications leading up to a DTN capability. To assist the reader in understanding where important conclusions are drawn, summary boxes are used at the end of some discussions to highlight a particular conclusion.
Summary Boxes
Information provided in a summary box provides an important summary of information provided in a more verbose form earlier in the text.
These boxes assist with both forward and backward looking content. When reading through a set of text looking forward to the summary can provide a good context on where a particular set of reasoning is going. Alternatively, readers might read summary boxes first to identify the text that is of most interest for reading.
1.3.3 Margin Notes
Margin notes serve as very short reminders of important concepts covered in the text of a chapter. They are placed partially in the margins to indicate that they are not part of the regular flow of information but, instead, are annotative in nature.
Margin Notes
These notes contain terse content reminders.
These notes are used for a variety of purposes. They emphasize important information in a section of text near the location of the note. They remind readers of information defined elsewhere in a chapter, or in some other chapter, that is important to placing existing text into context. They also identify the implications of something being discussed in the text.
1.3.4 Extract Quotes
A significant goal of this book is to explain the design decisions (and normative processing) of DTN security specifications. To that end, major design and processing directives related to BPv7 and BPSec are addressed. When doing so, the text of the relative specifications is quoted.
Similar to cipher suites, security policies are based on the nature and capabilities of individual networks and network operational concepts.
BPSec, RFC 9172 §1.2, [7]
This convention provides a straightforward mapping of discussion concepts and normative behavior. Additionally, the quoted text is indexed in the back of this book by the specification and section to help readers rapidly find information of interest.
1.3.5 Definitions
Custom definitions are used to ensure that terms with unique meanings in the context of DTN are not conflated with similar terms from other networking disciplines.
Definition 1.1 (Definitions): Unique terminology that is either highlighted in specifications related to DTN security, or otherwise as uniquely introduced in this book.
1.4 Organization
This book is organized into three sections: (i) security considerations for delay-tolerant networks, (ii) the design, implementation, and customization of the BPSec security extensions, and (iii) how this protocol can be applied, combined with other security protocols, and deployed in emerging network environments.
The first section presents the challenges of securing disrupted networks. The section starts with an observation that network architectures are over-constrained by how we provide security services and that there is an important distinction between cryptography as a discipline and the security protocols used to exchange cryptographic materials. This is followed by a discussion of the unique stressors found in delay-tolerant networks and how these stressing conditions break many of the protocols used to secure the Internet. Finally, this section discusses the characteristics of a security architecture for delay-tolerant networks and the unique security considerations that must be considered when defining a delay-tolerant security protocol.
The second section focuses on the history and development of BPv7 and the BPSec security extensions, starting with their unique design principles and those practices borrowed from more traditional security protocols such as those comprising the Internet Protocol Security (IPSec) and the Transport Layer Security (TLS) protocol suites. Next, the mechanisms used to represent cryptographic materials in bundles are discussed along with rules used for the processing of BPSec materials. This section concludes with a discussion of two unique and enabling characteristics of the BPSec protocol: security context definitions and out-of-band policy configurations.
The third section discusses pragmatic considerations for deploying BPSec in both regular and delay-tolerant networks. This section discusses how the protocol can be extended to encounter a variety of methods for defining and communicating cryptographic material. This is followed by a discussion of design patterns associated with the use of BPSec security services and some network-level use cases that build upon these patterns. Finally, this section concludes with a discussion of what can go wrong along the way when deploying BPSec in a challenged network.
1.5 Summary
The desire to more pervasively instrument both our world and our celestial neighborhood has challenged computer networking researchers to develop new algorithms and protocols. These new approaches to data communication must operate in conditions fundamentally dissimilar to today's Internet.
However, the design of network protocols are built around the capabilities of the underlying networking architecture. Therefore, if these new challenged networks cannot provide the same operational guarantees as the Internet, then IPs might not behave the same when used in these new environments.
This book addresses fundamental questions related to how data communications can be secured in challenged networks, with a focus on networks that use BPv7 for transport services and BPSec extensions for securing BPv7 bundles. In doing so, the motivation, design, and behavior of the design of the BPSec are explained.
References
1
Feldmann, A., Gasser, O., Lichtblau, F., Pujol, E., Poese, I., Dietzel, C., Wagner, D., Wichtlhuber, M., Tapiador, J., Vallina-Rodriguez, N., Hohlfeld, O. and Smaragdakis, G. [2021]. Implications of the COVID-19 pandemic on the internet traffic,
Broadband Coverage in Germany; 15th ITG-Symposium
, pp. 1–5.
2
Sparks, P. [2017]. The route to a trillion devices,
White Paper, ARM
.
3
Schaefer, M. T. [2008]. Bios robotlab writing robot.jpg. License: CC BY 2.0,
https://creativecommons.org/licenses/by/2.0viaWikimediaCommons
. URL:
https://commons.wikimedia.org/wiki/File:Bios_robotlab_writing_robot.jpg
.
4
Birrane, E. J., Copeland, D. J. and Ryschkewitsch, M. G. [2017]. The path to space-terrestrial internetworking,
2017 IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE)
, pp. 134–139.
5
Burleigh, S., Fall, K. and Birrane, E. J. [2022]. Bundle Protocol Version 7, RFC 9171. URL:
https://www.rfc-editor.org/info/rfc9171
.
6
Kasprzyk, A. [2019]. Iso-model-threats-network-protection.png. License: CC BY 3.0,
https://creativecommons.org/licenses/by/3.0viaWikimediaCommons
. URL:
https://commons.wikimedia.org/wiki/File:ISO-model-threats-network-protection.png
.
7
Birrane, E. J. and McKeever, K. [2022]. Bundle Protocol Security (BPSec), RFC 9172. URL:
https://www.rfc-editor.org/info/rfc9172
.
2Network Design Considerations
More and more unique network architectures are being developed to extend data communications into increasingly remote areas on Earth, in near-Earth space, and throughout the solar system. Projects that seek to build computer networks in new environments representing new domains must rethink both architecture and design activities to uncover unique design constraints. This chapter discusses how constraints and network architectural patterns impact design activities and why new transport and security mechanisms might be needed in these new and exotic deployments.
After reading this chapter you will be able to:
Summarize how constraints impact network design and implementation.
Describe the security implications of a layered networking architecture.
Distinguish between the roles of cryptography and network security.
Compare different strategies for configuring cryptographic functions when used in a network.
