draft-ietf-6man-ipv6-alt-mark-00.txt   draft-ietf-6man-ipv6-alt-mark-01.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: December 1, 2020 M. Cociglio Expires: December 24, 2020 M. Cociglio
Telecom Italia Telecom Italia
F. Qin F. Qin
China Mobile China Mobile
May 30, 2020 R. Pang
China Unicom
June 22, 2020
IPv6 Application of the Alternate Marking Method IPv6 Application of the Alternate Marking Method
draft-ietf-6man-ipv6-alt-mark-00 draft-ietf-6man-ipv6-alt-mark-01
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 the passive performance measurement tool in an IPv6 domain and as the passive performance measurement tool in an IPv6 domain and
reports implementation considerations. It proposes how to define a reports implementation considerations. It proposes how to define a
new Extension Header Option to encode alternate marking technique and new Extension Header Option to encode alternate marking technique and
both Hop-by-Hop Options Header and Destination Options Header are both Hop-by-Hop Options Header and Destination Options Header are
considered. considered.
Requirements Language 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 RFC 2119 document are to be interpreted as described in BCP 14 [RFC2119]
[RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all [RFC8174] when, and only when, they appear in all capitals, as shown
capitals, as shown here. here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 1, 2020. This Internet-Draft will expire on December 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 35 skipping to change at page 2, line 35
3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4
4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 5 4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 5
5. Alternate Marking Method Operation . . . . . . . . . . . . . 7 5. Alternate Marking Method Operation . . . . . . . . . . . . . 7
5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7 5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7
5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 8 5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 8
5.3. Flow Monitoring Identification . . . . . . . . . . . . . 9 5.3. Flow Monitoring Identification . . . . . . . . . . . . . 9
5.3.1. Uniqueness of FlowMonID . . . . . . . . . . . . . . . 10 5.3.1. Uniqueness of FlowMonID . . . . . . . . . . . . . . . 10
5.4. Multipoint and Clustered Alternate Marking . . . . . . . 10 5.4. Multipoint and Clustered Alternate Marking . . . . . . . 10
5.5. Data Collection and Calculation . . . . . . . . . . . . . 11 5.5. Data Collection and Calculation . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe a passive [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe a passive
performance measurement method, which can be used to measure packet performance measurement method, which can be used to measure packet
loss, latency and jitter on live traffic. Since this method is based loss, latency and jitter on live traffic. Since this method is based
on marking consecutive batches of packets, the method is often on marking consecutive batches of packets, the method is often
referred as Alternate Marking Method. referred as Alternate Marking Method.
The Alternate Marking Method has become mature to be implemented and The Alternate Marking Method has become mature to be implemented and
skipping to change at page 3, line 26 skipping to change at page 3, line 26
IPv6 domain. The case of SRH ([RFC8754]) is also discussed, anyway IPv6 domain. The case of SRH ([RFC8754]) is also discussed, anyway
this is valid for all the types of Routing Header (RH). this is valid for all the types of Routing Header (RH).
2. Alternate Marking application to IPv6 2. Alternate Marking application to IPv6
The Alternate Marking Method requires a marking field. As mentioned, The Alternate Marking Method requires a marking field. As mentioned,
several alternatives have been analysed in several alternatives have been analysed in
[I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers, [I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,
IPv6 Address and Flow Label. IPv6 Address and Flow Label.
The only correct and robust choice that can actually be standardized In consequence to the previous document and to the discussion within
would be the use of a new TLV to be encoded in the Options Header the community, it is possible to state that the only correct and
(Hop-by-Hop or Destination Option). robust choice that can actually be standardized would be the use of a
new TLV to be encoded in the Options Header (Hop-by-Hop or
Destination Option).
This approach is compliant with [RFC8200] indeed the Alternate This approach is compliant with [RFC8200] indeed the Alternate
Marking application to IPv6 involves the following operations: Marking application to IPv6 involves the following operations:
o The source node is the only one that writes the Option Header to o The source node is the only one that writes the Option Header to
mark alternately the flow (for both Hop-by-Hop and Destination mark alternately the flow (for both Hop-by-Hop and Destination
Option). Option).
o In case of Hop-by-Hop Option Header carrying Alternate Marking o In case of Hop-by-Hop Option Header carrying Alternate Marking
bits, it is not inserted or deleted, but can be read by any node bits, it is not inserted or deleted, but can be read by any node
skipping to change at page 9, line 48 skipping to change at page 9, line 48
Similar to packet delay measurement (both for Single Marking and Similar to packet delay measurement (both for Single Marking and
Double Marking), the method can also be used to measure the inter- Double Marking), the method can also be used to measure the inter-
arrival jitter. arrival jitter.
5.3. Flow Monitoring Identification 5.3. Flow Monitoring Identification
The Flow Monitoring Identification (FlowMonID) is required for some The Flow Monitoring Identification (FlowMonID) is required for some
general reasons: general reasons:
First, it helps to reduce the per node configuration. Otherwise, o First, it helps to reduce the per node configuration. Otherwise,
each node needs to configure an access-control list (ACL) for each each node needs to configure an access-control list (ACL) for each
of the monitored flows. Moreover, using a flow identifier allows of the monitored flows. Moreover, using a flow identifier allows
a flexible granularity for the flow definition. a flexible granularity for the flow definition.
Second, it simplifies the counters handling. Hardware processing o Second, it simplifies the counters handling. Hardware processing
of flow tuples (and ACL matching) is challenging and often incurs of flow tuples (and ACL matching) is challenging and often incurs
into performance issues, especially in tunnel interfaces. into performance issues, especially in tunnel interfaces.
Third, it eases the data export encapsulation and correlation for o Third, it eases the data export encapsulation and correlation for
the collectors. the collectors.
The FlowMon identifier field is to uniquely identify a monitored flow The FlowMon identifier field is to uniquely identify a monitored flow
within the measurement domain. The field is set at the source node. within the measurement domain. The field is set at the source node.
The FlowMonID can be uniformly assigned by the central controller or The FlowMonID can be uniformly assigned by the central controller or
algorithmically generated by the source node. The latter approach algorithmically generated by the source node. The latter approach
cannot guarantee the uniqueness of FlowMonID but it may be preferred cannot guarantee the uniqueness of FlowMonID but it may be preferred
for local or private network, where the conflict probability is small for local or private network, where the conflict probability is small
due to the large FlowMonID space. due to the large FlowMonID space.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
The nodes enabled to perform performance monitoring collect the value The nodes enabled to perform performance monitoring collect the value
of the packet counters and timestamps. There are several of the packet counters and timestamps. There are several
alternatives to implement Data Collection and Calculation, but this alternatives to implement Data Collection and Calculation, but this
is not specified in this document. is not specified in this document.
6. Security Considerations 6. Security Considerations
This document aims to apply a method to perform measurements that This document aims to apply a method to perform measurements that
does not directly affect Internet security nor applications that run does not directly affect Internet security nor applications that run
on the Internet. However, implementation of this method must be on the Internet. However, implementation of this method must be
mindful of security and privacy concerns.There are two types of mindful of security and privacy concerns.
security concerns: potential harm caused by the measurements and
potential harm to the measurements.
Security concerns are limited since the method implies modifications There are two types of security concerns: potential harm caused by
to an Option of the data packets but this must be performed in a way the measurements and potential harm to the measurements.
that doesn't alter the quality of service experienced by packets
subject to measurements and that preserves stability of nodes. In
addition, an attacker cannot gain information about network
performance from a monitoring node; it must use synchronized
monitoring nodes at multiple points on the path but this is very
difficult since the alternate methodology is applied only in the
context of a controlled domain.
Privacy concerns are also limited because the method only relies on Harm caused by the measurement: Alternate Marking implies
information contained in the Option Header without any release of modifications on the fly to an Option Header of IPv6 packets but this
user data. must be performed in a way that does not alter the quality of service
experienced by the packets and that preserves stability and
performance of routers doing the measurements. The advantage of the
Alternate Marking method is that the marking bits are the only
information that is exchanged between the network nodes. Therefore,
network reconnaissance through passive eavesdropping on data-plane
traffic does not allow attackers to gain information about the
network performance. Moreover, Alternate Marking should usually be
applied in a controlled domain and this also helps to limit the
problem.
Harm to the Measurement: Alternate Marking measurements could be
harmed by routers altering the marking of the packets or by an
attacker injecting artificial traffic. Since the measurement itself
may be affected by network nodes along the path intentionally
altering the value of the marking bits of IPv6 packets, the Alternate
Marking should be applied in the context of a controlled domain,
where the network nodes are locally administered and this type of
attack can be avoided. Indeed the source and destination addresses
are within the controlled domain and therefore it is unlikely subject
to hijacking of packets, because it is possible to filter external
packets at the domain boundaries. In addition, an attacker cannot
gain information about network performance from a single monitoring
point; it must use synchronized monitoring points at multiple points
on the path, because they have to do the same kind of measurement and
aggregation as Alternate Marking requires.
The privacy concerns of network measurement are limited because the
method only relies on information contained in the Option Header
without any release of user data. Although information in the Option
Header is metadata that can be used to compromise the privacy of
users, the limited marking technique seems unlikely to substantially
increase the existing privacy risks from header or encapsulation
metadata.
The Alternate Marking application described in this document relies
on an 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 [RFC7384].
7. IANA Considerations 7. IANA Considerations
The Option Type should be assigned in IANA's "Destination Options and The Option Type should be assigned in IANA's "Destination Options and
Hop-by-Hop Options" registry. Hop-by-Hop Options" registry.
This draft requests the following IPv6 Option Type assignments from This draft requests the following IPv6 Option Type assignments from
the Destination Options and Hop-by-Hop Options sub-registry of the Destination Options and Hop-by-Hop Options sub-registry of
Internet Protocol Version 6 (IPv6) Parameters Internet Protocol Version 6 (IPv6) Parameters
(https://www.iana.org/assignments/ipv6-parameters/). (https://www.iana.org/assignments/ipv6-parameters/).
skipping to change at page 13, line 15 skipping to change at page 13, line 48
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013, DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>. <https://www.rfc-editor.org/info/rfc7045>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
skipping to change at page 14, line 4 skipping to change at page 14, line 41
Email: zhoutianran@huawei.com Email: zhoutianran@huawei.com
Mauro Cociglio Mauro Cociglio
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: mauro.cociglio@telecomitalia.it Email: mauro.cociglio@telecomitalia.it
Fengwei Qin Fengwei Qin
China Mobile China Mobile
32 Xuanwumenxi Ave. 32 Xuanwumenxi Ave.
Beijing 100032 Beijing 100032
China China
Email: qinfengwei@chinamobile.com Email: qinfengwei@chinamobile.com
Ran Pang
China Unicom
9 Shouti South Rd.
Beijing 100089
China
Email: pangran@chinaunicom.cn
 End of changes. 17 change blocks. 
32 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/