Export of UDP Options Information in IP Flow Information Export (IPFIX)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 July 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is widely deployed in operators networks for traffic management purposes. The protocol specifies the encoding of a set of basic data types and how the various Information Elements (IEs) are transmitted. In order to support the export of new flow-related measurement data, new IEs can be defined and registered in a dedicated IANA registry [IANA-IPFIX] for interoperability.¶

This document specifies new IPFIX Information Elements for UDP options (Section 4). A brief overview of UDP options is provided in Section 3.¶

The IE specified in Section 4.1 uses the new abstract data type defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].¶

Examples to illustrate the use of the new IPFIX Information Elements are provided in Section 5.¶

2. Conventions and Definitions

This document uses the IPFIX-specific terminology (e.g., Flow) defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized.¶

Also, this document uses the terms defined in Section 3 of [I-D.ietf-tsvwg-udp-options].¶

3. UDP Options at a Glance

UDP [RFC0768] does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP [RFC9293], SCTP [RFC9260], or DCCP [RFC4340]. Such a mechanism can be useful for various applications, e.g., discover a path MTU or share timestamps. To fill that void, [I-D.ietf-tsvwg-udp-options] extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, [I-D.ietf-tsvwg-udp-options] uses trailers. Concretely, UDP options are placed in the surplus area (that is, the area of an IP payload that follows a UDP packet). See Figure 1. An example of the use of UDP options is described in [I-D.ietf-tsvwg-udp-options-dplpmtud].¶

                       IP transport payload
          <------------------------------------------------->
+--------+---------+----------------------+------------------+
| IP Hdr | UDP Hdr |     UDP user data    |   surplus area   |
+--------+---------+----------------------+------------------+
          <------------------------------>
                     UDP Length

Section 4.1 introduces a new IE to export the observed UDP options.¶

Options indicated by Kind values in the range 0-191 are called SAFE options. Such options can be silently ignored by legacy receivers because they do not alter the UDP user data (Section 11 of [I-D.ietf-tsvwg-udp-options]).¶

Options indicated by Kind values in the range 192-255 are called UNSAFE options. Such options are not safe for legacy receivers to ignore because they alter the UDP user data (Section 12 of [I-D.ietf-tsvwg-udp-options]).¶

UDP options occur per-packet within a Flow and can be inserted at any time in the Flow.¶

[I-D.ietf-tsvwg-udp-options] reserves two options for experiments: the Experimental option (EXP, Kind=127) for SAFE options and the UNSAFE Experimental option (UEXP, Kind=254). For both options, Experimental ID (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. Section 4.2 specifies a new IPFIX IE to export observed ExIDs in the EXP options. Also, Section 4.3 specifies a new IPFIX IE to export observed ExIDs in the UEXP options. Only 16-bit ExIDs are supported in [I-D.ietf-tsvwg-udp-options].¶

This document does not intend to elaborate operational guidance/implications of UDP options. The document focuses exclusively on exporting observed UDP options in datagrams.¶

4. New UDP IPFIX Information Elements

• Note: "URL_IANA_UDP_OPTIONS" is the URL of the "UDP Option Kind Numbers" registry group while "URL_IANA_UDP_ExIDs" is the URL of the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry that will be created by IANA as per Section 25 of [I-D.ietf-tsvwg-udp-options].¶

5. Examples

Given UDP kind allocation in Section 10 of [I-D.ietf-tsvwg-udp-options] and the option mapping defined in Section 4.1 of this document, fewer octets are likely to be used for Flows with mandatory UDP options.¶

Figure 2 shows an example of reported values in a udpOptions IE for a Flow in which End of Options List (EOL) and Alternate payload checksum (APC) options are observed. One octet is sufficient to report these observed options. Concretely, the reported udpOptions IE will be set to 0x05.¶

MSB                                                     LSB
                     1                          25
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|   |0|0|0|0|0|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+

Let us now consider a UDP Flow in which both SAFE and UNSAFE Experimental options are observed. Let us also consider that the observed SAFE Experimental options have ExIDs set to 0x9858 and 0xE2D4, and UNSAFE Experimental options have ExIDs set to 0xC3D9 and 0x9858. As shown in Figure 3, the following IEs are used to report these observed ExIDs:¶

1. udpSafeExperimentalOptionExID IE set to 0x9858E2D4 to report observed ExIDs of SAFE Experimental options.¶

2. udpUnsafeExperimentalOptionExID IE set to 0xC3D99658 to report the ExIDs of the observed UNSAFE Experimental options.¶

udpSafeExperimentalOptionExID IE:

MSB                                                          LSB
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              0x9858           |             0xE2D4            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

udpUnsafeExperimentalOptionExID IE:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              0xC3D9           |             0x9658            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Security Considerations

This document does not introduce new security considerations other than those already discussed in Section 8 of [RFC7012].¶

The reader may refer to Section 22 of [I-D.ietf-tsvwg-udp-options] for the security considerations related to UDP options.¶

7. IANA Considerations

This document requests IANA to add the following new IEs to the IANA registry entitled "IP Flow Information Export (IPFIX) Entities" [IANA-IPFIX]:¶

Acknowledgments

Thanks to Benoît Claise for the discussion on the ordering of IPFIX IEs. Thanks to Paul Aitken for the review and comments.¶

Thanks to Tommy Pauly for the tsvart review and Joe Touch for the intdir review.¶

Thanks to Thomas Graf for the Shepherd review.¶

Authors' Addresses