| < draft-ietf-6man-ipv6-alt-mark-13.txt | draft-ietf-6man-ipv6-alt-mark-14.txt > | |||
|---|---|---|---|---|
| 6MAN Working Group G. Fioccola | 6MAN Working Group G. Fioccola | |||
| Internet-Draft T. Zhou | Internet-Draft T. Zhou | |||
| Intended status: Standards Track Huawei | Intended status: Standards Track Huawei | |||
| Expires: October 2, 2022 M. Cociglio | Expires: October 30, 2022 M. Cociglio | |||
| Telecom Italia | Telecom Italia | |||
| F. Qin | F. Qin | |||
| China Mobile | China Mobile | |||
| R. Pang | R. Pang | |||
| China Unicom | China Unicom | |||
| March 31, 2022 | April 28, 2022 | |||
| IPv6 Application of the Alternate Marking Method | IPv6 Application of the Alternate Marking Method | |||
| draft-ietf-6man-ipv6-alt-mark-13 | draft-ietf-6man-ipv6-alt-mark-14 | |||
| Abstract | Abstract | |||
| This document describes how the Alternate Marking Method can be used | This document describes how the Alternate Marking Method can be used | |||
| as a passive performance measurement tool in an IPv6 domain. It | as a passive performance measurement tool in an IPv6 domain. It | |||
| defines a new Extension Header Option to encode Alternate Marking | defines a new Extension Header Option to encode Alternate Marking | |||
| information in both the Hop-by-Hop Options Header and Destination | information in both the Hop-by-Hop Options Header and Destination | |||
| Options Header. | Options Header. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on October 2, 2022. | This Internet-Draft will expire on October 30, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
| 3. Definition of the AltMark Option . . . . . . . . . . . . . . 7 | 3. Definition of the AltMark Option . . . . . . . . . . . . . . 7 | |||
| 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 7 | 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 8 | 4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 8 | |||
| 5. Alternate Marking Method Operation . . . . . . . . . . . . . 10 | 5. Alternate Marking Method Operation . . . . . . . . . . . . . 10 | |||
| 5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 10 | 5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 10 | |||
| 5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 12 | 5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 12 | |||
| 5.3. Flow Monitoring Identification . . . . . . . . . . . . . 13 | 5.3. Flow Monitoring Identification . . . . . . . . . . . . . 13 | |||
| 5.4. Multipoint and Clustered Alternate Marking . . . . . . . 15 | 5.4. Multipoint and Clustered Alternate Marking . . . . . . . 15 | |||
| 5.5. Data Collection and Calculation . . . . . . . . . . . . . 16 | 5.5. Data Collection and Calculation . . . . . . . . . . . . . 16 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 20 | 9.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 1. Introduction | 1. Introduction | |||
| [I-D.fioccola-rfc8321bis] and [I-D.fioccola-rfc8889bis] describe a | [I-D.ietf-ippm-rfc8321bis] and [I-D.ietf-ippm-rfc8889bis] describe a | |||
| passive performance measurement method, which can be used to measure | passive performance measurement method, which can be used to measure | |||
| packet loss, latency and jitter on live traffic. Since this method | packet loss, latency and jitter on live traffic. Since this method | |||
| is based on marking consecutive batches of packets, the method is | is based on marking consecutive batches of packets, the method is | |||
| often referred to as the Alternate Marking Method. | often referred to as the Alternate Marking Method. | |||
| This document defines how the Alternate Marking Method can be used to | This document defines how the Alternate Marking Method can be used to | |||
| measure performance metrics in IPv6. The rationale is to apply the | measure performance metrics in IPv6. The rationale is to apply the | |||
| Alternate Marking methodology to IPv6 and therefore allow detailed | Alternate Marking methodology to IPv6 and therefore allow detailed | |||
| packet loss, delay and delay variation measurements both hop-by-hop | packet loss, delay and delay variation measurements both hop-by-hop | |||
| and end-to-end to exactly locate the issues in an IPv6 network. | and end-to-end to exactly locate the issues in an IPv6 network. | |||
| skipping to change at page 3, line 30 ¶ | skipping to change at page 3, line 30 ¶ | |||
| domain. | domain. | |||
| The threat model for the application of the Alternate Marking Method | The threat model for the application of the Alternate Marking Method | |||
| in an IPv6 domain is reported in Section 6. As with all on-path | in an IPv6 domain is reported in Section 6. As with all on-path | |||
| telemetry techniques, the only definitive solution is that this | telemetry techniques, the only definitive solution is that this | |||
| methodology MUST be applied in a controlled domain. | methodology MUST be applied in a controlled domain. | |||
| 1.1. Terminology | 1.1. Terminology | |||
| This document uses the terms related to the Alternate Marking Method | This document uses the terms related to the Alternate Marking Method | |||
| as defined in [I-D.fioccola-rfc8321bis] and | as defined in [I-D.ietf-ippm-rfc8321bis] and | |||
| [I-D.fioccola-rfc8889bis]. | [I-D.ietf-ippm-rfc8889bis]. | |||
| 1.2. Requirements Language | 1.2. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Alternate Marking application to IPv6 | 2. Alternate Marking application to IPv6 | |||
| skipping to change at page 8, line 8 ¶ | skipping to change at page 8, line 8 ¶ | |||
| this Option if they do not recognize and that the data of this | this Option if they do not recognize and that the data of this | |||
| Option do not change en route, indeed the source is the only one | Option do not change en route, indeed the source is the only one | |||
| that can write it. | that can write it. | |||
| o Opt Data Len: 4. It is the length of the Option Data Fields of | o Opt Data Len: 4. It is the length of the Option Data Fields of | |||
| this Option in bytes. | this Option in bytes. | |||
| o FlowMonID: 20-bit unsigned integer. The FlowMon identifier is | o FlowMonID: 20-bit unsigned integer. The FlowMon identifier is | |||
| described in Section 5.3. As further discussed below, it has been | described in Section 5.3. As further discussed below, it has been | |||
| picked as 20 bits since it is a reasonable value and a good | picked as 20 bits since it is a reasonable value and a good | |||
| compromise in relation to the chance of collision if it is set | compromise in relation to the chance of collision. It MUST be set | |||
| pseudo randomly by the source node or set by a centralized | pseudo randomly by the source node or by a centralized controller. | |||
| controller. | ||||
| o L: Loss flag for Packet Loss Measurement as described in | o L: Loss flag for Packet Loss Measurement as described in | |||
| Section 5.1; | Section 5.1; | |||
| o D: Delay flag for Single Packet Delay Measurement as described in | o D: Delay flag for Single Packet Delay Measurement as described in | |||
| Section 5.2; | Section 5.2; | |||
| o Reserved: is reserved for future use. These bits MUST be set to | o Reserved: is reserved for future use. These bits MUST be set to | |||
| zero on transmission and ignored on receipt. | zero on transmission and ignored on receipt. | |||
| skipping to change at page 10, line 17 ¶ | skipping to change at page 10, line 16 ¶ | |||
| it is important to be aware that the things may be different in the | it is important to be aware that the things may be different in the | |||
| implementation and it can happen that packets with Hop-by-Hop are | implementation and it can happen that packets with Hop-by-Hop are | |||
| forced onto the slow path, but this is a general issue, as also | forced onto the slow path, but this is a general issue, as also | |||
| explained in [I-D.hinden-6man-hbh-processing]. It is also worth | explained in [I-D.hinden-6man-hbh-processing]. It is also worth | |||
| mentioning that the application to a controlled domain should avoid | mentioning that the application to a controlled domain should avoid | |||
| the risk of arbitrary nodes dropping packets with Hop-by-Hop Options. | the risk of arbitrary nodes dropping packets with Hop-by-Hop Options. | |||
| 5. Alternate Marking Method Operation | 5. Alternate Marking Method Operation | |||
| This section describes how the method operates. | This section describes how the method operates. | |||
| [I-D.fioccola-rfc8321bis] introduces several applicable methods which | [I-D.ietf-ippm-rfc8321bis] introduces several applicable methods | |||
| are reported below, and a new field is introduced to facilitate the | which are reported below, and a new field is introduced to facilitate | |||
| deployment and improve the scalability. | the deployment and improve the scalability. | |||
| 5.1. Packet Loss Measurement | 5.1. Packet Loss Measurement | |||
| The measurement of the packet loss is really straightforward in | The measurement of the packet loss is really straightforward in | |||
| comparison to the existing mechanisms, as detailed in | comparison to the existing mechanisms, as detailed in | |||
| [I-D.fioccola-rfc8321bis]. The packets of the flow are grouped into | [I-D.ietf-ippm-rfc8321bis]. The packets of the flow are grouped into | |||
| batches, and all the packets within a batch are marked by setting the | batches, and all the packets within a batch are marked by setting the | |||
| L bit (Loss flag) to a same value. The source node can switch the | L bit (Loss flag) to a same value. The source node can switch the | |||
| value of the L bit between 0 and 1 after a fixed number of packets or | value of the L bit between 0 and 1 after a fixed number of packets or | |||
| according to a fixed timer, and this depends on the implementation. | according to a fixed timer, and this depends on the implementation. | |||
| The source node is the only one that marks the packets to create the | The source node is the only one that marks the packets to create the | |||
| batches, while the intermediate nodes only read the marking values | batches, while the intermediate nodes only read the marking values | |||
| and identify the packet batches. By counting the number of packets | and identify the packet batches. By counting the number of packets | |||
| in each batch and comparing the values measured by different network | in each batch and comparing the values measured by different network | |||
| nodes along the path, it is possible to measure the packet loss | nodes along the path, it is possible to measure the packet loss | |||
| occurred in any single batch between any two nodes. Each batch | occurred in any single batch between any two nodes. Each batch | |||
| represents a measurable entity recognizable by all network nodes | represents a measurable entity recognizable by all network nodes | |||
| along the path. | along the path. | |||
| Both fixed number of packets and fixed timer can be used by the | Both fixed number of packets and fixed timer can be used by the | |||
| source node to create packet batches. But, as also explained in | source node to create packet batches. But, as also explained in | |||
| [I-D.fioccola-rfc8321bis], the timer-based batches are preferable | [I-D.ietf-ippm-rfc8321bis], the timer-based batches are preferable | |||
| because they are more deterministic than the counter-based batches. | because they are more deterministic than the counter-based batches. | |||
| There is no definitive rule for counter-based batches, differently | There is no definitive rule for counter-based batches, differently | |||
| from timer-based batches. Using a fixed timer for the switching | from timer-based batches. Using a fixed timer for the switching | |||
| offers better control over the method, indeed the length of the | offers better control over the method, indeed the length of the | |||
| batches can be chosen large enough to simplify the collection and the | batches can be chosen large enough to simplify the collection and the | |||
| comparison of the measures taken by different network nodes. In the | comparison of the measures taken by different network nodes. In the | |||
| implementation the counters can be sent out by each node to the | implementation the counters can be sent out by each node to the | |||
| controller that is responsible for the calculation. It is also | controller that is responsible for the calculation. It is also | |||
| possible to exchange this information by using other on-path | possible to exchange this information by using other on-path | |||
| techniques. But this is out of scope for this document. | techniques. But this is out of scope for this document. | |||
| Packets with different L values may get swapped at batch boundaries, | Packets with different L values may get swapped at batch boundaries, | |||
| and in this case, it is required that each marked packet can be | and in this case, it is required that each marked packet can be | |||
| assigned to the right batch by each router. It is important to | assigned to the right batch by each router. It is important to | |||
| mention that for the application of this method there are two | mention that for the application of this method there are two | |||
| elements to consider: the clock error between network nodes and the | elements to consider: the clock error between network nodes and the | |||
| network delay. These can create offsets between the batches and out- | network delay. These can create offsets between the batches and out- | |||
| of-order of the packets. The mathematical formula on timing aspects, | of-order of the packets. The mathematical formula on timing aspects, | |||
| explained in section 5 of [I-D.fioccola-rfc8321bis], must be | explained in section 5 of [I-D.ietf-ippm-rfc8321bis], must be | |||
| satisfied and it takes into considerations the different causes of | satisfied and it takes into considerations the different causes of | |||
| reordering such as clock error and network delay. The assumption is | reordering such as clock error and network delay. The assumption is | |||
| to define the available counting interval where to get stable | to define the available counting interval where to get stable | |||
| counters and to avoid these issues. Specifically, if the effects of | counters and to avoid these issues. Specifically, if the effects of | |||
| network delay are ignored, the condition to implement the methodology | network delay are ignored, the condition to implement the methodology | |||
| is that the clocks in different nodes MUST be synchronized to the | is that the clocks in different nodes MUST be synchronized to the | |||
| same clock reference with an accuracy of +/- B/2 time units, where B | same clock reference with an accuracy of +/- B/2 time units, where B | |||
| is the fixed time duration of the batch, which refers to the original | is the fixed time duration of the batch, which refers to the original | |||
| marking interval at the source node considering that this interval | marking interval at the source node considering that this interval | |||
| could fluctuate along the path. In this way each marked packet can | could fluctuate along the path. In this way each marked packet can | |||
| skipping to change at page 14, line 20 ¶ | skipping to change at page 14, line 20 ¶ | |||
| the collectors. | the collectors. | |||
| The FlowMonID MUST only be used as a monitored flow identifier in | The FlowMonID MUST only be used as a monitored flow identifier in | |||
| order to determine a monitored flow within the measurement domain. | order to determine a monitored flow within the measurement domain. | |||
| This entails not only an easy identification but improved correlation | This entails not only an easy identification but improved correlation | |||
| as well. | as well. | |||
| The value of 20 bits has been selected for the FlowMonID since it is | The value of 20 bits has been selected for the FlowMonID since it is | |||
| a good compromise and implies a low rate of ambiguous FlowMonIDs that | a good compromise and implies a low rate of ambiguous FlowMonIDs that | |||
| can be considered acceptable in most of the applications. The | can be considered acceptable in most of the applications. The | |||
| disambiguation issue is more visible when the FlowMonID is pseudo | disambiguation issue can be solved by tagging the pseudo randomly | |||
| randomly generated but, it can be solved by tagging the FlowMonID | generated FlowMonID with additional flow information. In particular, | |||
| with additional flow information. In particular, it is RECOMMENDED | it is RECOMMENDED to consider the 3-tuple FlowMonID, source and | |||
| to consider the 3-tuple FlowMonID, source and destination addresses: | destination addresses: | |||
| o If the 20 bit FlowMonID is set independently and pseudo randomly | o If the 20 bit FlowMonID is set independently and pseudo randomly | |||
| in a distributed way there is a chance of collision. Indeed, by | in a distributed way there is a chance of collision. Indeed, by | |||
| using the well-known birthday problem in probability theory, if | using the well-known birthday problem in probability theory, if | |||
| the 20 bit FlowMonID is set independently and pseudo randomly | the 20 bit FlowMonID is set independently and pseudo randomly | |||
| without any additional input entropy, there is a 50% chance of | without any additional input entropy, there is a 50% chance of | |||
| collision for 1206 flows. So, for more entropy, FlowMonID is | collision for 1206 flows. So, for more entropy, FlowMonID is | |||
| combined with source and destination addresses. Since there is a | combined with source and destination addresses. Since there is a | |||
| 1% chance of collision for 145 flows, it is possible to monitor | 1% chance of collision for 145 flows, it is possible to monitor | |||
| 145 concurrent flows per host pairs with a 1% chance of collision. | 145 concurrent flows per host pairs with a 1% chance of collision. | |||
| o If the 20 bits FlowMonID is set in a centralized way, the | o If the 20 bits FlowMonID is set pseudo randomly but in a | |||
| controller can instruct the nodes properly in order to guarantee | centralized way, the controller can instruct the nodes properly in | |||
| the uniqueness of the FlowMonID. With 20 bits, the number of | order to guarantee the uniqueness of the FlowMonID. With 20 bits, | |||
| combinations is 1048576, and the controller should ensure that all | the number of combinations is 1048576, and the controller should | |||
| the FlowMonID values are used without any collision. Therefore, | ensure that all the FlowMonID values are used without any | |||
| by considering source and destination addresses together with the | collision. Therefore, by considering source and destination | |||
| FlowMonID, it can be possible to monitor 1048576 concurrent flows | addresses together with the FlowMonID, it can be possible to | |||
| per host pairs. | monitor 1048576 concurrent flows per host pairs. | |||
| A consistent approach MUST be used in the Alternate Marking | A consistent approach MUST be used in the Alternate Marking | |||
| deployment to avoid the mixture of different ways of identifying. | deployment to avoid the mixture of different ways of identifying. | |||
| All the nodes along the path and involved into the measurement SHOULD | All the nodes along the path and involved into the measurement SHOULD | |||
| use the same mode for identification. As mentioned, it is | use the same mode for identification. As mentioned, it is | |||
| RECOMMENDED to use the FlowMonID for identification purpose in | RECOMMENDED to use the FlowMonID for identification purpose in | |||
| combination with source and destination addresses to identify a flow. | combination with source and destination addresses to identify a flow. | |||
| By considering source and destination addresses together with the | By considering source and destination addresses together with the | |||
| FlowMonID it can be possible to monitor 145 concurrent flows per host | FlowMonID it can be possible to monitor 145 concurrent flows per host | |||
| pairs with a 1% chance of collision in case of pseudo randomly | pairs with a 1% chance of collision in case of pseudo randomly | |||
| generated FlowMonID, or 1048576 concurrent flows per host pairs in | generated FlowMonID, or 1048576 concurrent flows per host pairs in | |||
| case of centralized controller. It is worth mentioning that the | case of centralized controller. It is worth mentioning that the | |||
| solution with the centralized control allows finer granularity and | solution with the centralized control allows finer granularity and | |||
| therefore adds even more flexibility to the flow identification. | therefore adds even more flexibility to the flow identification. | |||
| The FlowMonID field is set at the source node, which is the ingress | The FlowMonID field is set at the source node, which is the ingress | |||
| point of the measurement domain, and can be set in two ways: | point of the measurement domain, and can be set in two ways: | |||
| a. It can be algorithmically generated by the source node, that can | a. It can be algorithmically generated by the source node, that can | |||
| set it pseudo-randomly with some chance of collision. This | set it pseudo-randomly with some chance of collision. This | |||
| approach cannot guarantee the uniqueness of FlowMonID but, | approach cannot guarantee the uniqueness of FlowMonID since | |||
| considering the recommendation to use FlowMonID with source and | conflicts and collisions are possible. But, considering the | |||
| destination addresses the conflict probability is reduced due to | recommendation to use FlowMonID with source and destination | |||
| the FlowMonID space available for each endpoint pair (i.e. 145 | addresses the conflict probability is reduced due to the | |||
| flows with 1% chance of collision). | FlowMonID space available for each endpoint pair (i.e. 145 flows | |||
| with 1% chance of collision). | ||||
| b. It can be assigned by the central controller. Since the | b. It can be assigned by the central controller. Since the | |||
| controller knows the network topology, it can set the value | controller knows the network topology, it can allocate the value | |||
| properly to avoid or minimize ambiguity and guarantee the | properly to avoid or minimize ambiguity and guarantee the | |||
| uniqueness. In this regard, the controller can simply verify | uniqueness. In this regard, the controller can verify that there | |||
| that there is no ambiguity between different pseudo-randomly | is no ambiguity between different pseudo-randomly generated | |||
| generated FlowMonIDs on the same path. The conflict probability | FlowMonIDs on the same path. The conflict probability is really | |||
| is really small given that the FlowMonID is coupled with source | small given that the FlowMonID is coupled with source and | |||
| and destination addresses and up to 1048576 flows can be | destination addresses and up to 1048576 flows can be monitored | |||
| monitored for each endpoint pair. | for each endpoint pair. When all values in the FlowMonID space | |||
| are consumed, the centralized controller can keep track and | ||||
| reassign the values that are not used any more by old flows. | ||||
| If the FlowMonID is set by the source node, the intermediate nodes | If the FlowMonID is set by the source node, the intermediate nodes | |||
| can read the FlowMonIDs from the packets in flight and act | can read the FlowMonIDs from the packets in flight and act | |||
| accordingly. While, if the FlowMonID is set by the controller, both | accordingly. While, if the FlowMonID is set by the controller, both | |||
| possibilities are feasible for the intermediate nodes which can learn | possibilities are feasible for the intermediate nodes which can learn | |||
| by reading the packets or can be instructed by the controller. | by reading the packets or can be instructed by the controller. | |||
| When all values in the FlowMonID space are consumed, the centralized | ||||
| controller can keep track and reassign the values that are not used | ||||
| any more by old flows, while if the FlowMonID is pseudo randomly | ||||
| generated by the source, conflicts and collisions are possible. | ||||
| 5.4. Multipoint and Clustered Alternate Marking | 5.4. Multipoint and Clustered Alternate Marking | |||
| The Alternate Marking method can also be extended to any kind of | The Alternate Marking method can also be extended to any kind of | |||
| multipoint to multipoint paths, and the network clustering approach | multipoint to multipoint paths, and the network clustering approach | |||
| allows a flexible and optimized performance measurement, as described | allows a flexible and optimized performance measurement, as described | |||
| in [I-D.fioccola-rfc8889bis]. | in [I-D.ietf-ippm-rfc8889bis]. | |||
| The Cluster is the smallest identifiable subnetwork of the entire | The Cluster is the smallest identifiable subnetwork of the entire | |||
| Network graph that still satisfies the condition that the number of | Network graph that still satisfies the condition that the number of | |||
| packets that goes in is the same that goes out. With network | packets that goes in is the same that goes out. With network | |||
| clustering, it is possible to use the partition of the network into | clustering, it is possible to use the partition of the network into | |||
| clusters at different levels in order to perform the needed degree of | clusters at different levels in order to perform the needed degree of | |||
| detail. So, for Multipoint Alternate Marking, FlowMonID can identify | detail. So, for Multipoint Alternate Marking, FlowMonID can identify | |||
| in general a multipoint-to-multipoint flow and not only a point-to- | in general a multipoint-to-multipoint flow and not only a point-to- | |||
| point flow. | point flow. | |||
| skipping to change at page 17, line 21 ¶ | skipping to change at page 17, line 19 ¶ | |||
| type of attack can be avoided. For this reason, the implementation | type of attack can be avoided. For this reason, the implementation | |||
| of the method is not done on the end node if it is not fully managed | of the method is not done on the end node if it is not fully managed | |||
| and does not belong to the controlled domain. Packets generated | and does not belong to the controlled domain. Packets generated | |||
| outside the controlled domain may consume router resources by | outside the controlled domain may consume router resources by | |||
| maliciously using the HbH Option, but this can be mitigated by | maliciously using the HbH Option, but this can be mitigated by | |||
| filtering these packets at the controlled domain boundary. This can | filtering these packets at the controlled domain boundary. This can | |||
| be done because, if the end node does not belong to the controlled | be done because, if the end node does not belong to the controlled | |||
| domain, it is not supposed to add the AltMark HbH Option, and it can | domain, it is not supposed to add the AltMark HbH Option, and it can | |||
| be easily recognized. | be easily recognized. | |||
| An attacker that does not belong to the controlled domain can | ||||
| maliciously send packets with 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 MTU | ||||
| (by 48 bits). While if Alternate Marking is supported in the | ||||
| controlled domain, it is also necessary to avoid that the | ||||
| measurements are affected and external packets with 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) composes the AltMark Option together | The flow identifier (FlowMonID) composes the AltMark Option together | |||
| with the two marking bits (L and D). As explained in Section 5.3, | with the two marking bits (L and D). As explained in Section 5.3, | |||
| there is a chance of collision if the FlowMonID is set pseudo | there is a chance of collision if the FlowMonID is set pseudo | |||
| randomly and a solution exists. In general this may not be a problem | randomly and a solution exists. In general this may not be a problem | |||
| and a low rate of ambiguous FlowMonIDs can be acceptable, since this | and a low rate of ambiguous FlowMonIDs can be acceptable, since this | |||
| does not cause significant harm to the operators or their clients and | does not cause significant harm to the operators or their clients and | |||
| this harm may not justify the complications of avoiding it. But, for | this harm may not justify the complications of avoiding it. But, for | |||
| large scale measurements, a big number of flows could be monitored | large scale measurements, a big number of flows could be monitored | |||
| and the probability of a collision is higher, thus the disambiguation | and the probability of a collision is higher, thus the disambiguation | |||
| of the FlowMonID field can be considered. | of the FlowMonID field can be considered. | |||
| skipping to change at page 18, line 48 ¶ | skipping to change at page 19, line 9 ¶ | |||
| domain boundaries to filter both external packets with AltMark Option | domain boundaries to filter both external packets with AltMark Option | |||
| entering the domain and internal packets with AltMark Option leaving | entering the domain and internal packets with AltMark Option leaving | |||
| the domain. Therefore, the trusted domain is unlikely subject to | the domain. Therefore, the trusted domain is unlikely subject to | |||
| hijacking of packets since packets with AltMark Option are processed | hijacking of packets since packets with AltMark Option are processed | |||
| and used only within the controlled domain. | and used only within the controlled domain. | |||
| As stated, the application to a controlled domain ensures the control | As stated, the application to a controlled domain ensures the control | |||
| over the packets entering and leaving the domain, but despite that, | over the packets entering and leaving the domain, but despite that, | |||
| leakages may happen for different reasons, such as a failure or a | leakages may happen for different reasons, such as a failure or a | |||
| fault. In this case, nodes outside the domain MUST simply ignore | fault. In this case, nodes outside the domain MUST simply ignore | |||
| packets with AltMark Option since they should not process it. | packets with AltMark Option since they are not configured to handle | |||
| it and should not process it. | ||||
| Additionally, it is to be noted that the AltMark Option is carried by | Additionally, it is to be noted that the AltMark Option is carried by | |||
| the Options Header and it may have some impact on the packet sizes | the Options Header and it may have some impact on the packet sizes | |||
| for the monitored flow and on the path MTU, since some packets might | for the monitored flow and on the path MTU, since some packets might | |||
| exceed the MTU. However, the relative small size (48 bit in total) | exceed the MTU. However, the relative small size (48 bit in total) | |||
| of these Option Headers and its application to a controlled domain | of these Option Headers and its application to a controlled domain | |||
| help to mitigate the problem. | help to mitigate the problem. | |||
| It is worth mentioning that the security concerns may change based on | It is worth mentioning that the security concerns may change based on | |||
| the specific deployment scenario and related threat analysis, which | the specific deployment scenario and related threat analysis, which | |||
| skipping to change at page 20, line 22 ¶ | skipping to change at page 20, line 32 ¶ | |||
| The authors would like to thank Bob Hinden, Ole Troan, Martin Duke, | The authors would like to thank Bob Hinden, Ole Troan, Martin Duke, | |||
| Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren | Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren | |||
| Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood, Yoshifumi | Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood, Yoshifumi | |||
| Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky, | Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky, | |||
| Ron Bonica for the precious comments and suggestions. | Ron Bonica for the precious comments and suggestions. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [I-D.fioccola-rfc8321bis] | [I-D.ietf-ippm-rfc8321bis] | |||
| Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., Zhou, | Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., and | |||
| T., and X. Min, "Alternate-Marking Method", draft- | T. Zhou, "Alternate-Marking Method", draft-ietf-ippm- | |||
| fioccola-rfc8321bis-03 (work in progress), February 2022. | rfc8321bis-01 (work in progress), April 2022. | |||
| [I-D.fioccola-rfc8889bis] | [I-D.ietf-ippm-rfc8889bis] | |||
| Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T. | Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T. | |||
| Zhou, "Multipoint Alternate-Marking Method", draft- | Zhou, "Multipoint Alternate-Marking Clustered Method", | |||
| fioccola-rfc8889bis-03 (work in progress), February 2022. | draft-ietf-ippm-rfc8889bis-01 (work in progress), April | |||
| 2022. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| End of changes. 25 change blocks. | ||||
| 56 lines changed or deleted | 68 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||