Add support for network message padding (option_message_padding)

Previous research [1], [2] has shown that the Lightning Network is
susceptible to passive network-layer attacks on privacy that can exploit
metadata leaking from transmitted network messages.

While other factors such as timing come into play, the most severe
information leakage is due to the fact that a passive adversary
monitoring the Noise-encrypted network traffic can still observe clearly
distinguished network message sizes, which allows them to reliably
classify messages by type, and therefore in turn allows them to draw
conclusions on node behavior. In the worst case, this allows a purely
passive off-path adversary able to monitor traffic of multiple nodes on
a payment path to not only observe *that* a payment took place, but also
to identify the payment's endpoints.

To mitigate the information leakage coming from observable network
message sizes, we here propose the introduction of
`option_message_padding`, a simple protocol that allows Lightning
counterparties to opt into padding network messages to fixed size
thresholds large enough to cover `update_add_htlc` messages by including
suitably sized TLV records in all sent TLV stream `extension`s.

This approach will lead to uniform message size distribution for
'normal' day-to-day operations. Note however that messages beyond the
chosen size threshold will still stand out and leak some amount of
information. Moreover, note that we abstained from including padding for
custom messages, as it's not guaranteed that all application-layer
protocols are able to handle TLV streams according to
'it's-okay-to-be-odd' rules (see [3] for some questions around that).

[1]: https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/611970/paper.pdf
[2]: https://drops.dagstuhl.de/storage/00lipics/lipics-vol316-aft2024/LIPIcs.AFT.2024.12/LIPIcs.AFT.2024.12.pdf
[3]: #1302

Author: tnull

01-messaging.md

@@ -26,6 +26,7 @@ All data fields are unsigned big-endian unless otherwise specified.
     * [The `error` and `warning` Messages](#the-error-and-warning-messages)
   * [Control Messages](#control-messages)
     * [The `ping` and `pong` Messages](#the-ping-and-pong-messages)
+  * [Network Message Padding](#network-message-padding)
   * [Peer Storage](#peer-storage)
     * [The `peer_storage` and `peer_storage_retrieval` Messages](#the-peer_storage-and-peer_storage_retrieval-messages)
   * [Appendix A: BigSize Test Vectors](#appendix-a-bigsize-test-vectors)
@@ -130,10 +131,11 @@ messages, a `tlv_stream` is typically placed after all currently defined fields.
 The `type` is encoded using the BigSize format. It functions as a
 message-specific, 64-bit identifier for the `tlv_record` determining how the
 contents of `value` should be decoded. `type` identifiers below 2^16 are
-reserved for use in this specification. `type` identifiers greater than or equal
-to 2^16 are available for custom records. Any record not defined in this
-specification is considered a custom record. This includes experimental and
-application-specific messages.
+reserved for use in this specification. `type` identifiers greater than or
+equal to 2^16 are available for custom records (except 2^64-1, which is
+reserved for message padding). Any record not defined in this specification is
+considered a custom record. This includes experimental and application-specific
+messages.
 
 The `length` is encoded using the BigSize format signaling the size of
 `value` in bytes.
@@ -504,6 +506,64 @@ every message maximally).
 Finally, the usage of periodic `ping` messages serves to promote frequent key
 rotations as specified within [BOLT #8](08-transport.md).
 
+## Network Message Padding
+
+Peers that negotiate `option_message_padding` agree to pad transmitted network
+message sizes to obfuscate the length of the original payload.
+
+To this end, they append a TLV record with type `18446744073709551615`
+(BigSize/`u64` maximum value) in the `extension` [TLV
+stream](#type-length-value-format) of all messages following `Init`.
+
+1. `tlv_stream`: `padding_tlvs`
+2. types:
+   1. type: `18446744073709551615` (`padding_type`)
+   2. data:
+     * [`length*bytes`:`padding_bytes`]
+
+### Requirements:
+
+A sending node that negotiated `option_provide_storage`:
+
+  - SHOULD append a TLV record of `padding_type` in all sent Lightning messages if their type is less than `32768`.
+  - MUST NOT apply padding to custom messages (i.e., any with types `32768`-`65535`).
+  - SHOULD choose the size of `padding_bytes` so that all sent messages have a fixed payload size >= 1452 bytes pre-encryption (1486 bytes post).
+
+A receiving node that negotiated `option_provide_storage`:
+
+  - SHOULD ignore and discard the `padding_bytes` data.
+
+### Rationale:
+Unpadded network messages might, even though Noise-encrypted, leak information
+about their contents to observing third parties. Therefore, it's in order to
+minimize the information leakage by padding any transmitted network messages to
+the same target size, reaching a uniform distribution of network message sizes.
+
+The `padding_type` was chosen to be odd to allow receivers to trivially ignore
+and discard them according to 'it's-okay-to-be-odd' rules in a
+backwards-compatible manner. It was furthermore chosen to be the BigSize/`u64`
+maximum value to allow senders to append the padding TLV record as a last step
+without infringing on the `tlv_stream` ordering requirements Note that the
+padding MUST NOT be applied to custom messages as it's not guaranteed that all
+application layer protocols are able to handle a TLV `extension` and apply
+'it's-okay-to-be-odd' rules.
+
+While the specific padding strategies/thresholds employed are left to
+implementations, they SHOULD pad all messages sizes to fixed values that cover
+the largest message sizes during payment activity: In the base case, a
+serialized `update_add_htlc` message is 1452 bytes: 2 (`type`) + 32
+(`channel_id`) + 8 (`htlc_id`) + 8 (`amount_msat`) + 32 (`payment_hash`) + 4
+(`cltv_expiry`) + 1366 (`onion_routing_packet`). The Noise encryption step then
+adds 2 (encrypted message length) + 16 (encrypted message length MAC) bytes +
+16 (encrypted message MAC), resulting in 1486 bytes TCP payload. Therefore
+implementations SHOULD pad all messages resulting in uniform message sizes of
+of 1452 bytes pre- or 1486 post-encryption.
+
+Note however that this base case doesn't take into account any of the optional
+fields on `update_add_htlc`, so implementations might choose to set larger
+padding threshold to have `update_add_htlc` messages not stand out if any of
+these fields are included.
+
 ## Peer storage
 
 ### The `peer_storage` and `peer_storage_retrieval` Messages

09-features.md

@@ -55,6 +55,7 @@ The Context column decodes as follows:
 | 48/49 | `option_payment_metadata`         | Payment metadata in tlv record                            | 9        |                             | [BOLT #11](11-payment-encoding.md#tagged-fields)                      |
 | 50/51 | `option_zeroconf`                 | Understands zeroconf channel types                        | INT      | `option_scid_alias`         | [BOLT #2][bolt02-channel-ready]                                       |
 | 60/61 | `option_simple_close`             | Simplified closing negotiation                            | IN       | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close]                                        |
+| 64/65 | `option_message_padding`          | Network message padding                                   | I        |                             | [BOLT #1][bolt01-network-message-padding]                                     |
 
 ## Requirements
 
@@ -97,6 +98,7 @@ known to be set, and do not need to be validated at every feature gate.
 <br>
 This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
 
+[bolt01-network-message-padding]: 01-messaging.md#network-message-padding
 [bolt02-retransmit]: 02-peer-protocol.md#message-retransmission
 [bolt02-open]: 02-peer-protocol.md#the-open_channel-message
 [bolt02-simple-close]: 02-peer-protocol.md#closing-negotiation-closing_complete-and-closing_sig