Skip to main content

11. Security Considerations

This section preserves the RFC text for UDPSTP, including One-Way IP Capacity metrics, Control and Data phases, Load and Status Feedback PDUs, KDF/HMAC authentication, optional checksum handling, IANA registries, and security considerations.

Original RFC Text​

11.  Security Considerations

   Active metrics and measurements have a long history of security
   considerations.  The security considerations that apply to any active
   measurement of live paths are relevant here.  See [RFC4656] and
   [RFC5357].

   When considering privacy of users activating measurements as a
   service or users whose traffic is measured, the sensitive information
   available to potential observers is greatly reduced when using active
   techniques that are within this scope of work.  Passive observations
   of user traffic for measurement purposes raise many privacy issues.
   See the privacy considerations described in the LMAP Framework
   [RFC7594], which covers active and passive techniques.

   Below are some new considerations for capacity measurement as
   described in this document.

   1.  Cooperating client and server hosts and agreements to test the
       path between the hosts are REQUIRED.  Hosts perform in either the
       server or the client roles.  One way to assure a cooperative
       agreement employs the optional Authorization mode is through the
       use of the authDigest field and the known identity associated
       with the shared key used to create the authDigest field via the
       KDF.  Other means are also possible, such as access control lists
       at the server.

   2.  It is REQUIRED to have a user client-initiated setup handshake
       between cooperating hosts that allows firewalls to control
       inbound unsolicited UDP traffic that goes to either a control
       port or ephemeral ports that are only created as needed.
       Firewalls protecting each host can continue to do their jobs
       normally.

   3.  Client-server authentication and integrity protection for
       feedback messages conveying measurements is RECOMMENDED.  To
       accommodate different host limitations and testing circumstances,
       different modes of operation are available, as described in
       Section 5.

   4.  Hosts MUST limit the number of simultaneous tests to avoid
       resource exhaustion and inaccurate results.

   5.  Senders MUST be rate-limited.  This can be accomplished using a
       pre-built table defining all the offered sending rates that will
       be supported.  The default and optional load rate adjustment
       algorithm results in "ramp up" from the lowest rate in the table.
       Optionally, the server could utilize the maxBandwidth field (and
       the CHSR_USDIR_BIT bit) in the Setup Request from the client to
       limit the maximum that it will attempt to achieve.

   6.  Service subscribers with limited data volumes who conduct
       extensive capacity testing might experience the effects of
       Service Provider controls on their service.  Testing with the
       Service Provider's measurement hosts SHOULD be limited in
       frequency and/or overall volume of test traffic (for example, the
       range of test interval duration values should be limited).

   One specific attack that has been recognized is an on-path attack on
   the testAction field where the attacker would set or clear the STOP
   indication.  Setting the indication in successive packets terminates
   the test prematurely, with no threat to the Internet but annoyance
   for the testers.  If an attacker clears the STOP indication, the
   mitigation relies on knowledge of the test duration at the client and
   server, where these hosts cease all traffic when the specified test
   duration is complete.

   Authentication methods and requirements steadily evolve.  Alternate
   authentication modes provide for algorithm agility by defining a new
   mode, whose support is indicated by assigning a suitable "Test Setup
   PDU Authentication Mode" registry value (see Section 12.3.4 ).
Last updated on