====== 9. Security Model ======

===== 9.1 Purpose =====

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

===== 9.2 Design Intent =====

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

===== 9.3 Security Capabilities =====

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.

===== 9.4 Network Separation =====

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.

===== 9.5 Constrained Security =====

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

===== 9.6 Trust Boundaries =====

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

===== 9.7 Future Direction =====

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