Bundle Security Protocol Policy Enforcement in DTN2

Each BSP-enabled node serves as a policy enforcement point as it enforces some policy that controls the forwarding and delivery of bundles. Below is the description of how policies are applied to bundles sent and received by the current node for each of the mandatory ciphersuites.

BAB Outgoing Policy Enforcement

Enforce policy on ALL outgoing bundles.

• Enforce on bundles originating from node and bundles originating from neighbors.
• Node uses same key for all outgoing bundles.
• If key is missing, bundle remains on bundle list and is not transmitted. If key is present after daemon restart, node will apply BAB protection and transmit bundles on list.

BAB Incoming Policy Enforcement

Enforce policy on ALL incoming bundles

• Enforce on bundles destined for node and destined for neighbors.
• If bundle is not BAB protected, discard bundle permanently.
• If validation fails, discard bundle permanently. (Failure may be due to corrupted bundle, missing key file, wrong key, etc.)
• If BAB blocks are present in bundle, while incoming policy does not require BAB, bundle is accepted if it is successfully validated; otherwise, bundle is permanently discarded.

PCB Outgoing Policy Enforcement

Only enforce policy on bundles originating from node

• If encryption key is missing, bundle remains on bundle list and is not transmitted. If key is present after daemon restart, node will encrypt and transmit bundles saved on list.
• Currently supports use of a different key per bundle destination based on EID. Using different keys allows different encryption tunnels per bundle destination.

Do NOT enforce policy on bundles originating from neighbors

• If node is not the bundle source, node forwards bundle to next hop without enforcing local policy.

PCB Incoming Policy Enforcement

Only enforce policy on bundles destined for node

• If bundle is not encrypted, discard bundle permanently.
• If decryption fails, discard bundle permanently. (Failure could be due to corrupted bundle, missing key file, wrong key, etc.)
• If PCB blocks are present in bundle, while incoming policy does not require encryption, bundle is accepted if it was successfully decrypted; otherwise, bundle is permanently discarded.

Do NOT enforce policy on bundles not destined for node

• If node is not the bundle destination, node forwards bundle to next hop without enforcing local policy.

PIB Outgoing Policy Enforcement

Only enforce policy on bundles originating from node

• If signing key is missing, bundle remains on bundle list and is not transmitted. If key is present after daemon restart, node will sign and transmit bundles saved on list.

Do NOT enforce policy on bundles originating from neighbors

• If node is not the bundle source, node forwards bundle to next hop without enforcing local policy.

PIB Incoming Policy Enforcement

Only enforce policy on bundles destined for node

• If signature is missing, discard bundle permanently.
• If verification fails, discard bundle permanently. (Failure could be due to corrupted bundle, missing key file, wrong key, etc.)
• If PIB blocks are present in bundle, while incoming policy does not require signatures, bundle is accepted if it was successfully verified; otherwise, bundle is permanently discarded.
• Currently supports use of a different public keys per bundle source based on EID.

Do NOT enforce policy on bundles not destined for node

• If node is not the bundle destination, node forwards bundle to next hop without enforcing local policy.

ESB Outgoing Policy Enforcement

Only enforce policy on bundles originating from node

• If encryption key is missing, bundle remains on bundle list and is not transmitted. If key is present after daemon restart, node will encrypt extension blocks and transmit bundles on list.
• Currently supports use of a different key per bundle destination based on EID. Using different keys allows different encryption tunnels per bundle destination.

Do NOT enforce policy on bundles originating from neighbors

• If node is not the bundle source, node forwards bundle to next hop without enforcing local policy.

ESB Incoming Policy Enforcement

• Due to the wide range of possible block types for extension blocks, we currently do not support enforcing a security policy for incoming ESB blocks.
• If ESB blocks are present in bundle, bundle is accepted if it was successfully decrypted; otherwise, bundle is permanently discarded.