This document defines the current security posture and intended security boundaries of MTRP.

MTRP is intended to operate across a range of node classes, from constrained devices to more capable bridge or core nodes.

The security model therefore distinguishes between:

• protocol participation
• transport capability
• security capability
• trust policy

Security capability values indicate the forms of security a node or transport may support.

Examples include:

• NONE
• AES128
• AES256

Capability signaling does not, by itself, guarantee that a given message was validated under that capability. It describes support and configuration context.

The network identifier remains useful even in secure deployments.

A receiver SHOULD use the network identifier as an initial discriminator for intentional protocol traffic before more expensive processing is performed.

The network identifier is not, by itself, a security mechanism.

For constrained nodes, a reduced but practical security posture MAY be preferable to no security at all.

Constrained security behavior SHOULD favor:

• compact validation logic
• bounded memory impact
• compatibility with bridge-assisted architectures

MTRP currently assumes relatively simple trust behavior.

The current implementation does not fully define:

• authenticated neighbor admission
• key exchange
• replay-resistant secure sessions
• complete end-to-end trust validation
• secure group-delivery semantics

Likely future security work includes:

• stronger trusted-neighbor validation
• transport-specific security policy
• constrained-profile secure framing
• bridge-assisted security for limited radios
• reliable secure unicast behavior