draft-ietf-ippm-ioam-data-02.txt   draft-ietf-ippm-ioam-data-03.txt 
ippm F. Brockners ippm F. Brockners
Internet-Draft S. Bhandari Internet-Draft S. Bhandari
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: September 6, 2018 Cisco Expires: December 29, 2018 Cisco
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Leddy J. Leddy
Comcast Comcast
S. Youell S. Youell
JPMC JPMC
T. Mizrahi T. Mizrahi
Marvell Marvell
D. Mozes D. Mozes
P. Lapukhov P. Lapukhov
Facebook Facebook
R. Chang R. Chang
Barefoot Networks Barefoot Networks
D. Bernier D. Bernier
Bell Canada Bell Canada
J. Lemon J. Lemon
Broadcom Broadcom
March 5, 2018 June 27, 2018
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-02 draft-ietf-ippm-ioam-data-03
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
discusses the data fields and associated data types for in-situ OAM. discusses the data fields and associated data types for in-situ OAM.
In-situ OAM data fields can be embedded into a variety of transports In-situ OAM data fields can be embedded into a variety of transports
such as NSH, Segment Routing, Geneve, native IPv6 (via extension such as NSH, Segment Routing, Geneve, native IPv6 (via extension
header), or IPv4. In-situ OAM can be used to complement OAM header), or IPv4. In-situ OAM can be used to complement OAM
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 6, 2018. This Internet-Draft will expire on December 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 5 skipping to change at page 3, line 5
6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 27 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7.1. Creation of a new In-Situ OAM Protocol Parameters 7.1. Creation of a new In-Situ OAM Protocol Parameters
Registry (IOAM) Protocol Parameters IANA registry . . . . 28 Registry (IOAM) Protocol Parameters IANA registry . . . . 28
7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 28 7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 28
7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 29 7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 29
7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 29 7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 29
7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 29 7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 29
7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 29 7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 29
7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 29 7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 29
8. Manageability Considerations . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document defines data fields for "in-situ" Operations, This document defines data fields for "in-situ" Operations,
Administration, and Maintenance (IOAM). In-situ OAM records OAM Administration, and Maintenance (IOAM). In-situ OAM records OAM
information within the packet while the packet traverses a particular information within the packet while the packet traverses a particular
network domain. The term "in-situ" refers to the fact that the OAM network domain. The term "in-situ" refers to the fact that the OAM
data is added to the data packets rather than is being sent within data is added to the data packets rather than is being sent within
packets specifically dedicated to OAM. IOAM is to complement packets specifically dedicated to OAM. IOAM is to complement
mechanisms such as Ping or Traceroute, or more recent active probing mechanisms such as Ping or Traceroute, or more recent active probing
skipping to change at page 5, line 28 skipping to change at page 5, line 28
Encapsulation independence: Data formats for IOAM SHOULD be defined Encapsulation independence: Data formats for IOAM SHOULD be defined
in a transport-independent manner. IOAM applies to a variety of in a transport-independent manner. IOAM applies to a variety of
encapsulating protocols. A definition of how IOAM data fields are encapsulating protocols. A definition of how IOAM data fields are
carried by different transport protocols is outside the scope of this carried by different transport protocols is outside the scope of this
document. document.
Layering: If several encapsulation protocols (e.g., in case of Layering: If several encapsulation protocols (e.g., in case of
tunneling) are stacked on top of each other, IOAM data-records could tunneling) are stacked on top of each other, IOAM data-records could
be present at every layer. The behavior follows the ships-in-the- be present at every layer. The behavior follows the ships-in-the-
night model. night model, i.e. IOAM data in one layer is independent from IOAM
data in another layer. Layering allows operators to instrument the
protocol layer they want to measure. The different layers could, but
do not have to share the same IOAM encapsulation and decapsulation.
Combination with active OAM mechanisms: IOAM should be usable for Combination with active OAM mechanisms: IOAM should be usable for
active network probing, enabling for example a customized version of active network probing, enabling for example a customized version of
traceroute. Decapsulating IOAM nodes may have an ability to send the traceroute. Decapsulating IOAM nodes may have an ability to send the
IOAM information retrieved from the packet back to the source address IOAM information retrieved from the packet back to the source address
of the packet or to the encapsulating node. of the packet or to the encapsulating node.
IOAM implementation: The IOAM data-field definitions take the IOAM implementation: The IOAM data-field definitions take the
specifics of devices with hardware data-plane and software data-plane specifics of devices with hardware data-plane and software data-plane
into account. into account.
skipping to change at page 27, line 46 skipping to change at page 27, line 46
temporarily inaccurate. temporarily inaccurate.
6. IOAM Data Export 6. IOAM Data Export
IOAM nodes collect information for packets traversing a domain that IOAM nodes collect information for packets traversing a domain that
supports IOAM. IOAM decapsulating nodes as well as IOAM transit supports IOAM. IOAM decapsulating nodes as well as IOAM transit
nodes can choose to retrieve IOAM information from the packet, nodes can choose to retrieve IOAM information from the packet,
process the information further and export the information using process the information further and export the information using
e.g., IPFIX. e.g., IPFIX.
The discussion of IOAM data processing and export is left for a Raw data export of IOAM data using IPFIX is discussed in
future version of this document. [I-D.spiegel-ippm-ioam-rawexport].
7. IANA Considerations 7. IANA Considerations
This document requests the following IANA Actions. This document requests the following IANA Actions.
7.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM) 7.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM)
Protocol Parameters IANA registry Protocol Parameters IANA registry
IANA is requested to create a new protocol registry for "In-Situ OAM IANA is requested to create a new protocol registry for "In-Situ OAM
(IOAM) Protocol Parameters". This is the common registry that will (IOAM) Protocol Parameters". This is the common registry that will
skipping to change at page 29, line 45 skipping to change at page 29, line 45
meaning for Bit 1 - 7 are available for assignment via RFC Required meaning for Bit 1 - 7 are available for assignment via RFC Required
process as per [RFC8126]. process as per [RFC8126].
7.7. IOAM E2E Type Registry 7.7. IOAM E2E Type Registry
This registry defines code points for each bit in the 16 bit IOAM- This registry defines code points for each bit in the 16 bit IOAM-
E2E-Type field for IOAM E2E option Section 4.3. The meaning of Bit 0 E2E-Type field for IOAM E2E option Section 4.3. The meaning of Bit 0
- 3 are defined in this document. The meaning of Bit 4 - 15 are - 3 are defined in this document. The meaning of Bit 4 - 15 are
available for assignments via RFC Required process as per [RFC8126]. available for assignments via RFC Required process as per [RFC8126].
8. Manageability Considerations 8. Security Considerations
Manageability considerations will be addressed in a later version of As discussed in [RFC7276], a successful attack on an OAM protocol in
this document.. general, and specifically on IOAM, can prevent the detection of
failures or anomalies, or create a false illusion of nonexistent
ones.
9. Security Considerations The Proof of Transit option (Section Section 4.2) is used for
verifying the path of data packets. The security considerations of
POT are further discussed in [I-D.brockners-proof-of-transit].
Security considerations will be addressed in a later version of this The data elements of IOAM can be used for network reconnaissance,
document. allowing attackers to collect information about network paths,
performance, queue states, and other information.
10. Acknowledgements IOAM can be used as a means for implementing Denial of Service (DoS)
attacks, or for amplifying them. For example, a malicious attacker
can add an IOAM header to packets in order to consume the resources
of network devices that take part in IOAM or collectors that analyze
the IOAM data. Another example is a packet length attack, in which
an attacker pushes IOAM headers into data packets, causing these
packets to be increased beyond the MTU size, resulting in
fragmentation or in packet drops.
Since IOAM options may include timestamps, if network devices use
synchronization protocols then any attack on the time protocol
[RFC7384] can compromise the integrity of the timestamp-related data
fields.
At the management plane, attacks may be implemented by misconfiguring
or by maliciously configuring IOAM-enabled nodes in a way that
enables other attacks. Thus, IOAM configuration should be secured in
a way that authenticates authorized users and verifies the integrity
of configuration procedures.
Notably, IOAM is expected to be deployed in specific network domains,
thus confining the potential attack vectors to within the network
domain. Indeed, in order to limit the scope of threats to within the
current network domain the network operator is expected to enforce
policies that prevent IOAM traffic from leaking outside of the IOAM
domain, and prevent IOAM data from outside the domain to be processed
and used within the domain.
9. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and
Andrew Yourtchenko for the comments and advice. Andrew Yourtchenko for the comments and advice.
This document leverages and builds on top of several concepts This document leverages and builds on top of several concepts
described in [I-D.kitamura-ipv6-record-route]. The authors would described in [I-D.kitamura-ipv6-record-route]. The authors would
like to acknowledge the work done by the author Hiroshi Kitamura and like to acknowledge the work done by the author Hiroshi Kitamura and
people involved in writing it. people involved in writing it.
The authors would like to gracefully acknowledge useful review and The authors would like to gracefully acknowledge useful review and
insightful comments received from Joe Clarke, Al Morton, and Mickey insightful comments received from Joe Clarke, Al Morton, and Mickey
Spiegel. Spiegel.
11. References 10. References
11.1. Normative References 10.1. Normative References
[IEEE1588v2] [IEEE1588v2]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Std 1588-2008 - IEEE Standard for a Precision Clock Std 1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", IEEE Std 1588-2008, 2008, Control Systems", IEEE Std 1588-2008, 2008,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/1588-2008.html>. standard/1588-2008.html>.
[POSIX] Institute of Electrical and Electronics Engineers, "IEEE [POSIX] Institute of Electrical and Electronics Engineers, "IEEE
skipping to change at page 31, line 15 skipping to change at page 31, line 43
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
11.2. Informative References 10.2. Informative References
[I-D.hildebrand-spud-prototype] [I-D.brockners-proof-of-transit]
Hildebrand, J. and B. Trammell, "Substrate Protocol for Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
User Datagrams (SPUD) Prototype", draft-hildebrand-spud- Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
prototype-03 (work in progress), March 2015. of Transit", draft-brockners-proof-of-transit-05 (work in
progress), May 2018.
[I-D.ietf-ntp-packet-timestamps] [I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet- Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-00 (work in progress), October 2017. timestamps-02 (work in progress), June 2018.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-05 (work in progress), September 2017. nvo3-geneve-06 (work in progress), March 2018.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
in progress), October 2017. in progress), April 2018.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
November 2017. November 2017.
[I-D.kitamura-ipv6-record-route] [I-D.kitamura-ipv6-record-route]
Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
Option Extension", draft-kitamura-ipv6-record-route-00 Option Extension", draft-kitamura-ipv6-record-route-00
(work in progress), November 2000. (work in progress), November 2000.
[I-D.lapukhov-dataplane-probe] [I-D.lapukhov-dataplane-probe]
Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane
probe for in-band telemetry collection", draft-lapukhov- probe for in-band telemetry collection", draft-lapukhov-
dataplane-probe-01 (work in progress), June 2016. dataplane-probe-01 (work in progress), June 2016.
[I-D.spiegel-ippm-ioam-rawexport]
Spiegel, M., Brockners, F., Bhandari, S., and R.
Sivakolundu, "In-situ OAM raw data export with IPFIX",
draft-spiegel-ippm-ioam-rawexport-00 (work in progress),
March 2018.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, <https://www.rfc-
editor.org/info/rfc7276>.
[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>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, <https://www.rfc- DOI 10.17487/RFC7665, October 2015, <https://www.rfc-
editor.org/info/rfc7665>. editor.org/info/rfc7665>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way
 End of changes. 20 change blocks. 
32 lines changed or deleted 84 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/