[ippm] Mitigating replay threat in draft-ietf-ippm-asymmetrical-pkts

[Greg Mirsky <[e-mail]>]

Hi Tal,
thank you for your thoughtful question that prompted consideration of the
possible replay attack even in the presence of the HMAC TLV. One of the
useful mechanisms to mitigate the replay attack is having monotonically
increasing counter that can be compared to the previously received value. RFC
8762 <https://datatracker.ietf.org/doc/rfc8762/> is capable to measure
packet loss by using the Sequence Number maintained by the Session-Sender.
As a result, the Session-Reflector can use the value of the Sequence Number
field in the received STAMP test packet to detect potential replay attack.
Of course, the replay attack may be mistaken for the packet
re-ordering condition. Taking that into consideration, I propose the
following update to the Security Considerations:
OLD TEXT:
   Considering the potential number of reflected packets that can be
   generated by a single test packet sent to a Multicast address, when
   sending such messages a Session-Sender SHOULD sign packets using the
   HMAC TLV.
NEW TEXT:
   Considering the potential number of reflected packets that can be
   generated by a single test packet sent to a multicast address, a
   Session-Sender SHOULD sign packets using the HMAC TLV when sending
   such messages.  But even with the HMAC TLV, the Reflected Test Packet
   Control TLV could be exploited for the replay attack.  To mitigate
   that risk, a STAMP Session-Reflector SHOULD use the value of Sequence
   Number field [RFC8762] of the received STAMP test packet.  If that
   value compared to the received in the previous test packet of the
   same STAMP test session is not increasing, then the Session-Reflector
   MUST respond with a single reflected packet, setting the U flag to 1
   [RFC8972].

What are your thoughts?

Regards,
Greg