语境
我无法理解 SNMPv3 中的 USM 模型。我的研究和理解基于 RFC 3414。
我的问题是在 SNMP 的某些实现中没有强制执行身份验证，在我看来，这破坏了整个安全模型。
问题
用例是：
将带有 noAuthNoPriv 的 SNMPv3 TRAP 发送到配置的 USM 模型为 authPriv 的陷阱接收器必须接受或拒绝接收到的 TRAP。
我正在工作的女巫上的实施接受了 TRAP，我认为必须拒绝 TRAP。谁是对的？
我的研究 在RFC 3414 第 3.2 节处理传入的 SNMP 消息
文字说：
本节描述 SNMP 引擎在收到代表用户的包含管理操作的消息时遵循的过程
，具有特定的安全级别。.. 在第 5 步之前省略文本
如果有关用户的信息表明它不 支持调用者请求的安全级别，则增加 usmStatsUnsupportedSecLevels 计数器并将错误指示 (unsupportedSecurityLevel) 连同 OID 和增加的计数器的值一起返回给调用模块。
如果 securityLevel 指定要对消息进行身份验证，则根据用户的身份验证协议对消息进行身份验证。为此，根据抽象服务原语调用实现用户身份验证协议的身份验证模块：
我理解本文中的两条原则：
- 从第 5 步开始 -> USM 必须支持 TRAP 发送的级别，对我来说支持意味着等于。
- 从第 6 步开始 -> 身份验证必须成功
我的感觉
当我在客户端和服务器上设置身份验证时，我期望双重身份验证（客户端-服务器），或者至少客户端发送的消息经过身份验证。如果我错了，系统必须接受这个陷阱，这意味着任何人都可以代表任何人发送 SNMPv3 TRAP。
设置这个安全参数会给人一种错误的安全感，只有 SNMPv3 专家才能理解它的错误。在我看来，这是一个糟糕的选择，它可能会在多个地方造成很多安全漏洞。
旁注 INFORM 消息
我听说我需要使用 INFORM 而不是 TRAP 来获得完全验证的消息。但这不是我的问题，我真的很想了解 USM 模型。
旁注 我希望我是对的，否则，我感觉USM RFC SNMPv3写得不好（不是我可以做得更好），因为设置可以忽略的安全参数，给人一种虚假的安全感。
当我在客户端+服务器中设置身份验证时，我认为存在双重身份验证。如果我错了，没有，并且可以轻松地代表另一个系统发送 TRAP。
注意：我知道有 VACM，但我只关注来自相应 RFC 的 USM 的使用。我想了解 USM 的含义和用法，而不是执行相同任务的其他方式。