This document aims to apply a method to the performance measurements that does not directly affect Internet security nor applications that run on the Internet. However, implementation of this method must be mindful of security and privacy concerns.
There are two types of security concerns: potential harm caused by the measurements and potential harm to the measurements.
Harm caused by the measurement:
Alternate Marking implies the insertion of an Options Header to the IPv6packets by the source node, but this must be performed in a way that does notalter the quality of service experienced by the packets and that preservesstability and performance of routers doing the measurements. As alreadydiscussed in Section 4, the design of the AltMarkOption has been chosen with throughput in mind, such that it can beimplemented without affecting the user experience.
Harm to the measurement:
Alternate-Marking measurements could be harmed by routers altering thefields of the AltMark Option (e.g., marking of the packets or FlowMonID) or by amalicious attacker adding the AltMark Option to the packets in order to consumethe resources of network devices and entities involved. As described above,the source node is the only one that writes the Options Header while theintermediate nodes and destination node only read it without modifying theOptions Header. But, for example, an on-path attacker can modify the flags,whether intentionally or accidentally, or deliberately insert an Option to thepacket flow or delete the Option from the packet flow. The consequent effectcould be to give the appearance of loss or delay or to invalidate the measurementby modifying Option identifiers, such as FlowMonID. The malicious implicationcan be to cause actions from the network administrator where an interventionis not necessary or to hide real issues in the network. Since the measurementitself may be affected by network nodes intentionally altering the bits of theAltMark Option or injecting Options Headers as a means for Denial of Service(DoS), the Alternate Marking MUST be applied in the context ofa controlled domain, where the network nodes are locally administered and thistype of attack can be avoided. For this reason, the implementation of themethod is not done on the end node if it is not fully managed and does notbelong to the controlled domain. Packets generated outside the controlleddomain may consume router resources by maliciously using the Hop-by-Hop Option, butthis can be mitigated by filtering these packets at the controlled domainboundary. This can be done because if the end node does not belong to thecontrolled domain, it is not supposed to add the AltMark Hop-by-Hop Option, and itcan be easily recognized.
An attacker that does not belong to the controlled domain can maliciously send packets with the AltMark Option. But, if Alternate Marking is not supported in the controlled domain, no problem happens because the AltMark Option is treated as any other unrecognized Option and will not be considered by the nodes since they are not configured to deal with it; so, the only effect is the increased packet size (by 48 bits). If Alternate Marking is supported in the controlled domain, it is necessary to keep the measurements from being affected, and external packets with the AltMark Option MUST
be filtered. As any other Hop-by-Hop Options or Destination Options, it is possible to filter AltMark Options entering or leaving the domain, e.g., by using ACL extensions for filtering.
The flow identifier (FlowMonID), together with the two marking bits (L and D), comprises the AltMark Option. As explained in Section 5.3
, there is a chance of collision if the FlowMonID is set pseudo-randomly, but there is a solution for this issue. In general, this may not be a problem, and a low rate of ambiguous FlowMonIDs can be acceptable since this does not cause significant harm to the operators or their clients, and this harm may not justify the complications of avoiding it. But, for large scale measurements, a big number of flows could be monitored and the probability of a collision is higher; thus, the disambiguation of the FlowMonID field can be considered.
The privacy concerns also need to be analyzed even if the method only relies on information contained in the Options Header without any release of user data. Indeed, from a confidentiality perspective, although the AltMark Option does not contain user data, the metadata can be used for network reconnaissance to compromise the privacy of users by allowing attackers to collect information about network performance and network paths. The AltMark Option contains two kinds of metadata: the marking bits (L and D) and the flow identifier (FlowMonID).
The marking bits are the small information that is exchanged between the network nodes. Therefore, due to this intrinsic characteristic, network reconnaissance through passive eavesdropping on data plane traffic is difficult. Indeed, an attacker cannot gain information about network performance from a single monitoring point. The only way for an attacker can be to eavesdrop on multiple monitoring points at the same time, because they have to do the same kind of calculation and aggregation as Alternate Marking requires.
The FlowMonID field is used in the AltMark Option as the identifier of the monitored flow. It represents more sensitive information for network reconnaissance and may allow a flow tracking type of attack because an attacker could collect information about network paths.
Furthermore, in a pervasive surveillance attack, the information that can be derived over time is more. But, as further described hereinafter, the application of the Alternate Marking to a controlled domain helps to mitigate all the above aspects of privacy concerns.
At the management plane, attacks can be set up by misconfiguring or by maliciously configuring the AltMark Option. Thus, AltMark Option configuration MUST
be secured in a way that authenticates authorized users and verifies the integrity of configuration procedures. Solutions to ensure the integrity of the AltMark Option are outside the scope of this document. Also, attacks on the reporting of the statistics between the monitoring points and the network management system (e.g., centralized controller) can interfere with the proper functioning of the system. Hence, the channels used to report back flow statistics MUST
As stated above, the precondition for the application of the Alternate Marking is that it MUST
be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. A limited administrative domain provides the network administrator with the means to select, monitor, and control the access to the network, making it a trusted domain. In this regard, it is expected to enforce policies at the domain boundaries to filter both external packets with the AltMark Option entering the domain and internal packets with the AltMark Option leaving the domain. Therefore, the trusted domain is unlikely subject to the hijacking of packets since packets with AltMark Option are processed and used only within the controlled domain.
As stated, the application to a controlled domain ensures control over the packets entering and leaving the domain, but despite that, leakages may happen for different reasons such as a failure or a fault. In this case, nodes outside the domain are expected to ignore packets with the AltMark Option since they are not configured to handle it and should not process it.
Additionally, note that the AltMark Option is carried by the Options Header and it will have some impact on the packet sizes for the monitored flow and on the path MTU since some packets might exceed the MTU. However, the relative small size (48 bits in total) of these Options Headers and its application to a controlled domain help to mitigate the problem.
It is worth mentioning that the security concerns may change based on the specific deployment scenario and related threat analysis, which can lead to specific security solutions that are beyond the scope of this document. As an example, the AltMark Option can be used as a Hop-by-Hop or Destination Option and, in case of a Destination Option, multiple administrative domains may be traversed by the AltMark Option that is not confined to a single administrative domain. In this case, the user, who is aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes, but the controlled domain must be composed by more than one administrative domain. To this end, the inter-domain links need to be secured (e.g., by IPsec or VPNs) in order to avoid external threats and realize the whole controlled domain.
It might be theoretically possible to modulate the marking or the other fields of the AltMark Option to serve as a covert channel to be used by an on-path observer. This may affect both the data and management plane, but, here too, the application to a controlled domain helps to reduce the effects.
The Alternate-Marking application described in this document relies on a time synchronization protocol. Thus, by attacking the time protocol, an attacker can potentially compromise the integrity of the measurement. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC 7384
]. Network Time Security (NTS), described in [RFC 8915
], is a mechanism that can be employed. Also, the time, which is distributed to the network nodes through the time protocol, is centrally taken from an external accurate time source such as an atomic clock or a GPS clock. By attacking the time source, it is possible to compromise the integrity of the measurement as well. There are security measures that can be taken to mitigate the GPS spoofing attacks, and a network administrator should certainly employ solutions to secure the network domain.