RFC 5474

A Framework for Packet Selection and Reporting

📅 published March 2009, from ietf

Part 1 of 7 💖

RFC 5474: A Framework for Packet Selection and Reporting 🎀

Okay bestie, this is RFC 5474, published in March 2009 and marked Informational, which means it shares info with the Internet community and doesn't set any standard 🧚. The editor is N. Duffield from AT&T Labs - Research, and the other authors are D. Chiou (University of Texas), B. Claise (Cisco Systems, Inc.), A. Greenberg (Microsoft), M. Grossglauser (EPFL & Nokia), and J. Rexford (Princeton University). It belongs to the Network Working Group ✨. Its header doesn't list anything it obsoletes or updates, so it's a standalone doc 💅.

Status of This Memo

This memo is here to give info to the Internet community 🌸. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (c) 2009 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, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 📜.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exception is formatting it for publication as an RFC or translating it into languages other than English 🌈.

Abstract

This doc specifies a framework for the PSAMP (Packet SAMPling) protocol 🦋. PSAMP's jobs are to select packets from a stream according to a set of standardized Selectors, to build a stream of reports on the selected packets, and to export those reports to a Collector. The framework breaks down the parts of this architecture, then covers some generic requirements. Those come from two goals: ubiquitous deployment, and making the reports actually useful for applications. Detailed requirements for selection, reporting, and exporting are included, along with the configuration requirements for the PSAMP functions ✨.

Table of Contents

   1. Introduction ....................................................4
   2. PSAMP Documents Overview ........................................4
   3. Elements, Terminology, and High-Level Architecture ..............5
      3.1. High-Level Description of the PSAMP Architecture ...........5
      3.2. Observation Points, Packet Streams, and Packet Content .....5
      3.3. Selection Process ..........................................6
      3.4. Reporting ..................................................7
      3.5. Metering Process ...........................................8
      3.6. Exporting Process ..........................................8
      3.7. PSAMP Device ...............................................9
      3.8. Collector ..................................................9
      3.9. Possible Configurations ....................................9
   4. Generic Requirements for PSAMP .................................11
      4.1. Generic Selection Process Requirements ....................11
      4.2. Generic Reporting Requirements ............................12
      4.3. Generic Exporting Process Requirements ....................12
      4.4. Generic Configuration Requirements ........................13
   5. Packet Selection ...............................................13
      5.1. Two Types of Selectors ....................................13
      5.2. PSAMP Packet Selectors ....................................14
      5.3. Selection Fraction Terminology ............................17
      5.4. Input Sequence Numbers for Primitive Selectors ............18
      5.5. Composite Selectors .......................................19
      5.6. Constraints on the Selection Fraction .....................19
   6. Reporting ......................................................19
      6.1. Mandatory Contents of Packet Reports: Basic Reports .......19
      6.2. Extended Packet Reports ...................................20
      6.3. Extended Packet Reports in the Presence of IPFIX ..........20
      6.4. Report Interpretation .....................................21
   7. Parallel Metering Processes ....................................22
   8. Exporting Process ..............................................22
      8.1. Use of IPFIX ..............................................22
      8.2. Export Packets ............................................22
      8.3. Congestion-Aware Unreliable Transport .....................22
      8.4. Configurable Export Rate Limit ............................23
      8.5. Limiting Delay for Export Packets .........................23
      8.6. Export Packet Compression .................................24
      8.7. Collector Destination .....................................25
      8.8. Local Export ..............................................25
   9. Configuration and Management ...................................25
   10. Feasibility and Complexity ....................................26
      10.1. Feasibility ..............................................26
           10.1.1. Filtering .........................................26
           10.1.2. Sampling ..........................................26
           10.1.3. Hashing ...........................................26
           10.1.4. Reporting .........................................27
           10.1.5. Exporting .........................................27
      10.2. Potential Hardware Complexity ............................27
   11. Applications ..................................................28
      11.1. Baseline Measurement and Drill Down ......................29
      11.2. Trajectory Sampling ......................................29
      11.3. Passive Performance Measurement ..........................30
      11.4. Troubleshooting ..........................................30
   12. Security Considerations .......................................31
      12.1. Relation of PSAMP and IPFIX Security for
            Exporting Process ........................................31
      12.2. PSAMP Specific Privacy Considerations ....................31
      12.3. Security Considerations for Hash-Based Selection .........32
           12.3.1. Modes and Impact of Vulnerabilities ...............32
           12.3.2. Use of Private Parameters in Hash Functions .......33
           12.3.3. Strength of Hash Functions ........................33
      12.4. Security Guidelines for Configuring PSAMP ................34
   13. Contributors ..................................................34
   14. Acknowledgments ...............................................34
   15. References ....................................................34
      15.1. Normative References .....................................34
      15.2. Informative References ...................................35

1. Introduction ✨

This document describes the PSAMP framework, which lets network elements pick out subsets of packets using statistical and other methods, and then export a stream of reports on the selected packets to a Collector 💖.

PSAMP is motivated by the need for measurement-based support for network management and control across multivendor domains. That needs consistency across the whole domain in two things: the types of selection schemes available, and the way the resulting measurements are presented and interpreted 🍓.

The reasons behind each specific packet selection operation come from the applications they make possible. PSAMP development stays open to input from the requirements of standards in related IETF Working Groups, such as IP Performance Metrics (IPPM) [RFC2330] and Internet Traffic Engineering (TEWG) 🔥.

The name PSAMP is short for "Packet Sampling." The word "Sampling" captures the idea that only a subset of all the packets passing through a network element will be selected for reporting. PSAMP selection operations include random selection, deterministic selection (Filtering), and deterministic approximations to random selection (Hash-based Selection) 👑.

2. PSAMP Documents Overview 🦋

This document is one of a series of documents from the PSAMP group 🌈.

RFC 5474 (this document): "A Framework for Packet Selection and Reporting" describes the PSAMP framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector. Definitions of terminology and the use of the terms "must", "should", and "may" in this document are informational only.

  • [RFC5475]: "Sampling and Filtering Techniques for IP Packet Selection" describes the set of packet selection techniques supported by PSAMP.
  • [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications" specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process.
  • [RFC5477]: "Information Model for Packet Sampling Exports" defines an information and data model for PSAMP.

3. Elements, Terminology, and High-Level Architecture 🌸

3.1. High-Level Description of the PSAMP Architecture 💅

Here's an informal high-level look at the PSAMP protocol running in a PSAMP Device (we'll define all the terms in a sec 🫶). A stream of packets gets observed at an Observation Point. A Selection Process checks each packet to decide whether or not it gets selected for reporting. The Selection Process is part of the Metering Process, which builds a report on each selected packet using the Packet Content, and possibly other info like the packet treatment at the Observation Point or the arrival timestamp. An Exporting Process then sends the Packet Reports to a Collector, together with any subsidiary info needed to interpret them 🧚.

The figure below shows how the three processes (Selection, Metering, and Exporting) line up inside the PSAMP device ✨.

                +------------------+
                | Metering Process |
                | +-----------+    |     +-----------+
      Observed  | | Selection |    |     | Exporting |
      Packet--->| | Process   |--------->| Process   |--->Collector
      Stream    | +-----------+    |     +-----------+
                +------------------+

The next sections give detailed definitions of each of the objects we just named 💖.

3.2. Observation Points, Packet Streams, and Packet Content ✨

okay bestie, this section is all about the stuff that gets packets ready to feed into the Selection Process 🦋 Here are the terms you need:

  • Observation Point 🌸 An Observation Point is a spot in the network where IP packets can be observed. Examples are a line with a probe plugged into it, a shared medium like an Ethernet-based LAN, a single port on a router, or a set of interfaces (physical or logical) on a router.

Every Observation Point is tied to an Observation Domain, and one Observation Point can be a superset of several others. Like, one Observation Point can be a whole line card, and that would be the superset of all the individual Observation Points at that line card's interfaces. So lowkey it's giving nesting dolls 🪆

  • Observed Packet Stream 💜 The Observed Packet Stream is the set of all packets seen at the Observation Point. Simple, iconic.
  • Packet Stream 🌈 A Packet Stream is a set of packets from the Observed Packet Stream that flows past some specified point inside the Metering Process. An example is the output of the Selection Process. Here's the tea: packets that got selected (say, by Sampling) don't necessarily have any property that tells you they were picked, so they can't be told apart from packets that weren't selected. That's why the term "stream" is favored over "flow", which is defined as a set of packets with common properties [RFC3917]. Not me being picky, it's just a naming thing 💅
  • Packet Content 🍓 The Packet Content is the union of the packet header (which includes link layer, network layer, and other encapsulation headers) and the packet payload. Header plus payload, periodt.

3.3. Selection Process 🎀

this section defines the Selection Process and its related objects, so let's get into it 👑

  • Selection Process ✨ A Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output.
  • Selection State 🫶 A Selection Process may keep state information to use during selection. At any given time, the Selection State can depend on packets observed at and before that time, plus other variables. Examples include:
    • (i) sequence numbers of packets at the input of Selectors;
    • (ii) a timestamp of observation of the packet at the Observation Point;
    • (iii) iterators for pseudorandom number generators;
    • (iv) hash values calculated during selection;
    • (v) indicators of whether the packet was selected by a given Selector.

A Selection Process can change parts of the Selection State as it handles a packet. The Selection State for a packet reflects the state after the packet has been processed. Main character energy for real 🎬

  • Selector 🦋 A Selector defines what the Selection Process does to a single packet of its input. If the packet is selected, it becomes an element of the output Packet Stream.

A Selector can use the following information when deciding whether to select a packet:

  • (i) the Packet Content;
  • (ii) information derived from the packet's treatment at the Observation Point;
  • (iii) any Selection State that may be maintained by the Selection Process.
  • Composite Selector 🧚 A Composite Selector is an ordered composition of Selectors, where the output Packet Stream from one Selector becomes the input Packet Stream for the next one. It's like a relay race 🏃‍♀️
  • Primitive Selector 🌸 A Selector is primitive if it is not a Composite Selector. Basic, but essential.

3.4. Reporting 📝

okay so once packets are selected, we need to report on them 💖

  • Packet Reports 💜 Packet Reports are a configurable subset of a packet's input to the Selection Process. That can include the Packet Content, info about how the packet was treated (for example, the output interface), and its associated Selection State (for example, a hash of the Packet Content).
  • Report Interpretation 🌈 Report Interpretation is supporting info, relating to one or more packets, that's used to interpret their Packet Reports. Examples include configuration parameters of the Selection Process. Think of it as the decoder ring 🗝️
  • Report Stream 👑 The Report Stream is the output of a Metering Process. It has two distinct kinds of information in it: Packet Reports and Report Interpretation. Two types, one stream, no drama.

3.5. Metering Process 🔥

a Metering Process selects packets from the Observed Packet Stream using a Selection Process, and produces a Report Stream about the selected packets. Easy.

The PSAMP Metering Process can be seen as analogous to the IPFIX Metering Process [RFC5101], which produces Flow Records as its output. The difference is that the PSAMP Metering Process always contains a Selection Process. The relationship between PSAMP and IPFIX is further described in [RFC5477] and [RFC5474]. So they're besties, but PSAMP always brings a Selection Process to the party 🎉

3.6. Exporting Process 🧚

  • Exporting Process 🌸 An Exporting Process sends the output of one or more Metering Processes to one or more Collectors, in the form of Export Packets.
  • Export Packets 🎀 An Export Packet is a bundle of Report Interpretation(s) and/or one or more Packet Reports. The Exporting Process packs these into an Export Packet so it can be exported to a Collector. Packing it all up nice and neat 🎁

3.7. PSAMP Device 🌈

A PSAMP Device is a device hosting at least an Observation Point, a Metering Process (which includes a Selection Process), and an Exporting Process. Usually, the Observation Point(s), Metering Process(es), and Exporting Process(es) are co-located on this device, like at a router. Everything in one place, very efficient 💅

3.8. Collector 🫶

A Collector receives a Report Stream exported by one or more Exporting Processes. In some cases, the host of the Metering and/or Exporting Processes can also be the Collector. Wearing two hats, and slaying both 👑

3.9. Possible Configurations 🧚

okay so there are a few ways the high-level architecture of these elements can be set up. Here they are, bestie 🦋

 MP = Metering Process, EP = Exporting process

  PSAMP Device
 +---------------------+                 +------------------+
 |Observation Point(s) |                 | Collector(1)     |
 |MP(s)--->EP----------+---------------->|                  |
 |MP(s)--->EP----------+-------+-------->|                  |
 +---------------------+       |         +------------------+
                               |
  PSAMP Device                 |
 +---------------------+       |         +------------------+
 |Observation Point(s) |       +-------->| Collector(2)     |
 |MP(s)--->EP----------+---------------->|                  |
 +---------------------+                 +------------------+

  PSAMP Device
 +---------------------+
 |Observation Point(s) |
 |MP(s)--->EP---+      |
 |              |      |
 |Collector(3)<-+      |
 +---------------------+

The most simple Metering Process configuration is made up of:

          +------------------------------------+
          | +----------+                       |
          | |Selection |                       |
 Observed | |Process   |  Packet               |
 Packet-->| |(Primitive|-> Stream ->           |--> Report Stream
              ^
 Stream   | | Selector)|                       |
              ^
          | +----------+                       |
          |          Metering Process          |
          +------------------------------------+

A Metering Process with a Composite Selector is made up of:

          +--------------------------------------------------...
          | +-----------------------------------+
          | | +----------+         +----------+ |
          | | |Selection |         |Selection | |
 Observed | | |Process   |         |Process   | |
 Packet-->| | |(Primitive|-Packet->|(Primitive|---> Packet ...
                ^                    ^
 Stream   | | |Selector1)| Stream  |Selector2)| |   Stream
               ^                    ^
          | | +----------+         +----------+ |
          | |        Composite Selector         |
          | +-----------------------------------+
          |                   Metering Process
          +--------------------------------------------------...

            ...-------------+
                            |
                            |
                            |
                            |
                            |---> Report Stream
                            |
                            |
                            |
                            |
                            |
            ...-------------+

4. Generic Requirements for PSAMP 💫

this section lays out the generic requirements for the PSAMP protocol. A few of these get turned into specific requirements in later sections, so keep them in mind 🌸

4.1. Generic Selection Process Requirements 👑

  • (a) Ubiquity 💅 The Selectors must be simple enough to be implemented ubiquitously at maximal line rate.
  • (b) Applicability 🦋 The set of Selectors must be rich enough to support a range of existing and emerging measurement-based applications and protocols. This requires a workable trade-off between the range of traffic engineering applications and operational tasks it enables, and the complexity of the set of capabilities. Balance is everything 🧚
  • (c) Extensibility 🌈 The protocol must be able to accommodate additional packet Selectors not currently defined.
  • (d) Flexibility 🎀 The protocol must support selection of packets using various network protocols or encapsulation layers, including Internet Protocol Version 4 (IPv4) [RFC0791], Internet Protocol Version 6 (IPv6) [RFC2460], and Multiprotocol Label Switching (MPLS) [RFC3031].
  • (e) Robust Selection 🔥 Packet selection must be robust against attempts to craft an Observed Packet Stream from which packets are selected disproportionately (e.g., to evade selection or overload measurement systems). Nobody gets to rig the guest list 🙅‍♀️
  • (f) Parallel Metering Processes ✨ The protocol must support simultaneous operation of multiple independent Metering Processes at the same host.
  • (g) Causality 🫶 The selection decision for each packet should depend only weakly, if at all, upon future packets' arrivals. This promotes ubiquity by limiting the complexity of the selection logic.
  • (h) Encrypted Packets 🙈 Selectors that interpret packet fields must be configurable to ignore (i.e., not select) encrypted packets, when they are detected.

Specific Selectors are outlined in Section 5, and described in more detail in the companion document [RFC5475]. Stay tuned for the next part, because this is about to get good 🦋💜

4.2. Generic Reporting Requirements ✨

okay bestie, reporting time 📝 here's what the Report Stream has to do:

  • (i) Self-Defining: The Report Stream must be complete in the sense that no additional information need be retrieved from the Observation Point in order to interpret and analyze the reports. 🧠 the reports have to stand on their own, no extra digging back at the Observation Point needed
  • (j) Indication of Information Loss: The Report Stream must include sufficient information to indicate or allow the detection of loss occurring within the Selection, Metering, and/or Exporting Processes, or in transport. This may be achieved by the use of sequence numbers. 🕵️‍♀️ we need to be able to spot when stuff goes missing, and sequence numbers are one way to do that
  • (k) Accuracy: The Report Stream must include information that enables the accuracy of measurements to be determined. 🎯 the numbers need receipts so you can tell how accurate they are
  • (l) Faithfulness: All reported quantities that relate to the packet treatment must reflect the router state and configuration encountered by the packet at the time it is received by the Metering Process. 🪞 the report has to be honest about what the router was actually doing when the packet showed up
  • (m) Privacy: Although selection of the content of Packet Reports must be responsive to the needs of measurement applications, it must also conform with [RFC2804]. In particular, full packet capture of arbitrary Packet Streams is explicitly out of scope. 🔒 okay so measurement stuff has to actually be useful, BUT it also has to play by [RFC2804], and full packet capture of arbitrary Packet Streams is a hard no, not on the menu 🙅‍♀️
See Section 6 for further discussions on Reporting. 📖

4.3. Generic Exporting Process Requirements 🚀

  • (n) Timeliness: Configuration must allow for limiting of buffering delays for the formation and transmission for Export Packets. See Section 8.5 for further details. ⏱️ you should be able to cap how long stuff sits in a buffer before it gets formed and sent
  • (o) Congestion Avoidance: Export of a Report Stream across a network must be congestion avoiding in compliance with [RFC2914]. This is discussed further in Section 8.3. 🚦 exporting has to be a good network citizen, so no clogging the pipes, per [RFC2914]
  • (p) Secure Export: 🔐 this one is giving security main character energy
    • (i) confidentiality: The option to encrypt exported data must be provided. 🤫 encryption has to be an option you can actually turn on
    • (ii) integrity: Alterations in transit to exported data must be detectable at the Collector. 🧾 if someone messes with the data on the way, the Collector has to be able to notice
    • (iii) authenticity: Authenticity of exported data must be verifiable by the Collector in order to detect forged data. 🪪 the Collector needs a way to check that the data is legit and not fake

The motivation here is the same as for security in IPFIX export; see Sections 6.3 and 10 of [RFC3917]. 💅 same energy as IPFIX export security, so go check [RFC3917] if you want the full tea

4.4. Generic Configuration Requirements 🎀

  • (q) Ease of Configuration: This applies to ease of configuration of Sampling and export parameters, e.g., for automated remote reconfiguration in response to collected reports. 🧚 setting up Sampling and export stuff should be easy, even when it's being changed remotely based on what the reports show
  • (r) Secure Configuration: The option to configure via protocols that prevent unauthorized reconfiguration or eavesdropping on configuration communications must be available. Eavesdropping on configuration might allow an attacker to gain knowledge that would be helpful in crafting a Packet Stream to evade subversion or overload the measurement infrastructure. 😱 bestie this is serious. if somebody can snoop on configuration traffic, they could learn stuff that helps them build a Packet Stream to dodge the measurement or overload it, so the protocols you configure with need to block unauthorized changes and eavesdropping

Configuration is discussed in Section 9. 📖

5. Packet Selection 🦋

This section details specific requirements for the Selection Process, motivated by the generic requirements of Section 3.3. 💜 this part gets into the nitty gritty of how packets get picked, building on the big-picture stuff from Section 3.3

5.1. Two Types of Selectors 👑

PSAMP categorizes Selectors into two types:

  • Filtering: A filter is a Selector that selects a packet deterministically based on the Packet Content, or its treatment, or functions of these occurring in the Selection State. Two examples are:
    • (i) Property Match Filtering: A packet is selected if a specific field in the packet equals a predefined value. 🎯
    • (ii) Hash-based Selection: A hash function is applied to the Packet Content, and the packet is selected if the result falls in a specified range. 🪄
  • Sampling: A Selector that is not a filter is called a Sampling operation. This reflects the intuitive notion that if the selection of a packet cannot be determined from its content alone, there must be some type of Sampling taking place. 🎲 so if you can't decide just from the content, that's basically sampling, it's just vibes-based picking

Sampling operations can be divided into two subtypes:

  • (i) Content-independent Sampling: Does not use Packet Content in reaching Sampling decisions. Examples include systematic Sampling, and uniform pseudorandom Sampling driven by a pseudorandom number whose generation is independent of Packet Content. Note that in content-independent Sampling, it is not necessary to access the Packet Content in order to make the selection decision. 🙈 this one doesn't even look inside the packet, it's all about the pattern or the random number
  • (ii) Content-dependent Sampling: The Packet Content is used in reaching selection decisions. An application is pseudorandom selection with a probability that depends on the contents of a packet field, e.g., Sampling packets with a probability dependent on their TCP/UDP port numbers. Note that this is not a filter. 🧐 this one peeks at the packet contents to decide, but it still isn't a filter

5.2. PSAMP Packet Selectors 🌸

A spectrum of packet Selectors is described in detail in [RFC5475]. Here we only briefly summarize the meanings for completeness. 📚 the full breakdown lives in [RFC5475], this is the quick recap

A PSAMP Selection Process must support at least one of the following Selectors. ✅ so you need at least one of these to be supported

  • systematic count-based Sampling: Packet selection is triggered periodically by packet count, a number of successive packets being selected subsequent to each trigger. 🔁 every so many packets, a trigger goes off and a run of packets gets picked
  • systematic time-based Sampling: This is similar to systematic count-based Sampling except that selection is reckoned with respect to time rather than count. Packet selection is triggered at periodic instants separated by a time called the spacing. All packets that arrive within a certain time of the trigger (called the interval length) are selected. ⏰ same idea but it's clock-based instead of count-based: triggers go off at regular intervals, and everything arriving within the interval length after a trigger gets selected
  • probabilistic n-out-of-N Sampling: From each count-based successive block of N packets, n are selected at random. 🎰 chunk the packets into blocks of N and randomly grab n out of each block
  • uniform probabilistic Sampling: Packets are selected independently with fixed Sampling probability p. 🎯 every packet gets its own independent coin flip with the same odds, p
  • non-uniform probabilistic Sampling: Packets are selected independently with probability p that depends on Packet Content. 🧩 same independent coin flips, but the odds change depending on what's in the packet
  • Property Match Filtering: 💖 this is the big one for filters, let's break it down
    • With this Filtering method, a packet is selected if a specific field within the packet and/or on properties of the router state equal(s) a predefined value. Possible filter fields are all IPFIX Flow attributes specified in [RFC5102]. Further fields can be defined by vendor-specific extensions. 🧾 the fields you can match on are the IPFIX Flow attributes from [RFC5102], plus any extras vendors add
    • A packet is selected if Field=Value. Masks and ranges are only supported to the extent to which [RFC5102] allows them, e.g., by providing explicit fields like the netmasks for source and destination addresses. 🎭 so masks and ranges only work if [RFC5102] already lets you do them, like having separate netmask fields for source and destination addresses
    • AND operations are possible by concatenating filters, thus producing a composite selection operation. In this case, the ordering in which the Filtering happens is implicitly defined (outer filters come after inner filters). However, as long as the concatenation is on filters only, the result of the cascaded filter is independent from the order, but the order may be important for implementation purposes, as the first filter will have to work at a higher rate. In any case, an implementation is not constrained to respect the filter ordering, as long as the result is the same, and it may even implement the composite Filtering in one single step. 🔗 chaining filters together is how you do AND. the result doesn't depend on order, but the order can still matter for implementation, since the first filter has to keep up with the highest rate. Implementations can even do it all in one step if the result matches
    • OR operations are not supported with this basic model. More sophisticated filters (e.g., supporting bitmasks, ranges, or OR operations) can be realized as vendor-specific schemes. 🚫 no OR in this basic model, but fancier stuff like bitmasks, ranges, or OR can be done as vendor-specific schemes
    • Property match operations should be available for different protocol portions of the packet header:
      • (i) IP header (excluding options in IPv4, stacked headers in IPv6)
      • (ii) transport header
      • (iii) encapsulation headers (e.g., the MPLS label stack, if present)
    • When the PSAMP Device offers Property Match Filtering, and, in its usual capacity other than in performing PSAMP functions, identifies or processes information from IP, transport, or encapsulation protocols, then the information should be made available for Filtering. For example, when a PSAMP Device is a router that routes based on destination IP address, that field should be made available for Filtering. Conversely, a PSAMP Device that does not route is not expected to be able to locate an IP address within a packet, or make it available for Filtering, although it may do so. 🗺️ if the device already reads this info for its normal job, it should expose it for filtering. A device that doesn't route isn't expected to find an IP address, though it may still do it
    • Since packet encryption alters the meaning of encrypted fields, Property Match Filtering must be configurable to ignore encrypted packets when detected. 🔐 encrypted fields don't mean what they look like, so filtering has to be configurable to skip encrypted packets when it spots them
    • The Selection Process may support Filtering based on the properties of the router state:
      • (i) Ingress interface at which packet arrives equals a specified value
      • (ii) Egress interface to which packet is routed to equals a specified value
      • (iii) Packet violated Access Control List (ACL) on the router
      • (iv) Failed Reverse Path Forwarding (RPF). Packets that match the Failed Reverse Path Forwarding (RPF) condition are packets for which ingress Filtering failed as defined in [RFC3704].
      • (v) Failed Resource Reservation Protocol (RSVP). Packets that match the Failed RSVP condition are packets that do not fulfill the RSVP specification as defined in [RFC2205].
      • (vi) No route found for the packet
      • (vii) Origin Border Gateway Protocol (BGP) Autonomous System (AS) [RFC4271] equals a specified value or lies within a given range
      • (viii) Destination BGP AS equals a specified value or lies within a given range
    • Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access router state at line rate. However, when Filtering follows Sampling (or some other selection operation) in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently low that the filter could select based on router state. 🐢 the router's design might mean some treatment info isn't available at full speed. But if a sampler sits in front of the filter, the traffic coming out can be slow enough that the filter could use router state
  • Hash-based Selection: 🪄 okay last but not least
    • Hash-based Selection will employ one or more hash functions to be standardized. A hash function is applied to a subset of Packet Content, and the packet is selected if the resulting hash falls in a specified range. The stronger the hash function, the more closely Hash-based Selection approximates uniform random Sampling. Privacy of hash selection range and hash function parameters obstructs subversion of the Selector by packets that are crafted either to avoid selection or to be selected. Privacy of the hash function is not required. Robustness and security considerations of Hash-based Selection are further discussed in [RFC5475]. Applications of hash-based Sampling are described in Section 11. 🎀 a hash hits a slice of the packet content, and you select the packet if the hash lands in a range. A stronger hash looks more like uniform random Sampling. Keeping the range and hash parameters private stops packets from being crafted to dodge or get picked, but the hash function itself doesn't need to be private. More on robustness and security in [RFC5475], and the uses are in Section 11 💖

5.3. Selection Fraction Terminology ✨

okay so before we get into the fun stuff, we need the fraction vocab 🍓 bestie, this part is literally the math behind everything else

  • Population: A Population is a Packet Stream, or a subset of a Packet Stream. Think of it as the base set that packets get picked from, like all the packets in the Observed Packet Stream that were seen within some specified time interval 🕐
  • Population Size: the number of all packets in a Population 🔢
  • Sample Size: the number of packets a Selector picks out of the Population 🎯
  • Configured Selection Fraction: the expected ratio of Sample Size to Population Size, based on the selection parameters you configured 💅
  • Attained Selection Fraction: the ratio of the actual Sample Size to the Population Size 👑

ngl the gap between configured and attained is so real 🥺 for some Sampling methods the two can be different because of the inherent statistical variability in Sampling decisions. that's true for probabilistic Sampling and Hash-based Selection, for example. the good news? for big Population Sizes and properly configured Selectors, the Attained Selection Fraction usually gets close to the Configured one 🫶

the fraction idea doesn't stop at Selectors either 🦋 an illustrative example is the Configured Selection Fraction of the Metering Process composed with the Exporting Process. here the Population is the Observed Packet Stream or a subset of it. the Configured Selection Fraction is the fraction of the Population for which Packet Reports are expected to reach the Collector. this can depend on extra parameters that aren't necessarily described in the PSAMP protocol, like how much transmission bandwidth the Exporting Process has to work with 📡 in this case, the Attained Selection Fraction is the fraction of Population packets whose reports actually made it to the Collector, so it bakes in any loss of Packet Reports from resource contention at the Observation Point or during transmission. it's giving full-chain accounting 💜

5.4. Input Sequence Numbers for Primitive Selectors 🔢

okay this one is lowkey my favourite 😭 each instance of a Primitive Selector must keep a count of the packets presented at its input. that counter value is to be included as a sequence number for selected packets, and those sequence numbers count as part of the packet's Selection State 🧠

why does this matter? because input sequence numbers let applications work out the Attained Selection Fraction, which means they can correctly normalize network usage estimates no matter what got lost along the way 🙌 it doesn't matter whether the loss was Packet Reports getting discarded in the Metering Process (say, because the host was busy) or export packets getting lost in transmission or collection. see [RFC3176] for further details 📚

let's do an example bestie 🎀 imagine a set of n consecutive Packet Reports r1, r2,... , rn, selected by a Sampling operation and received at a Collector. say s1, s2,..., sn are the input sequence numbers reported by those packets. the Attained Selection Fraction for the composite of the measurement and Exporting Processes, counting both packet Sampling at the Observation Point and loss in transmission, is:

R = (n-1)/(sn-s1)

(fun fact: R would be 1 if every packet got selected and nothing got lost in transmission ✨)

the Attained Selection Fraction can then be used to estimate how many bytes were present in a chunk of the Observed Packet Stream 💖 let b1, b2,..., bn be the number of bytes reported in each packet that reached the Collector, and set:

B = b1+b2+...+bn

then the total bytes in packets from the Observed Packet Stream whose input sequence numbers sit between s1 and sn is estimated by:

B/R

which is basically scaling up the measured bytes by dividing by the Attained Selection Fraction 🦋

one more thing 🫶 with Composite Selectors, an input sequence number must be reported for each Selector in the composition. no skipping!

5.5. Composite Selectors 🧩

the ability to compose Selectors in a Selection Process should be provided, and these combos look like the most useful ones for applications:

  • concatenation of Property Match Filters. this is useful for building the AND of the component filters 💅
  • Filtering followed by Sampling
  • Sampling followed by Filtering

composite Selectors are super handy for drill-down applications 🔍 the first component can be used to reduce the load on the second one. honestly the ordering is the tea here: the advantage you get from a given ordering can depend on the composition of the Packet Stream, so it's not one-size-fits-all 🍵

5.6. Constraints on the Selection Fraction 🚦

sampling at full line rate, i.e., with probability 1, is not excluded in principle 👀 although resource constraints may not permit it in practice. so yes it's possible, just not always realistic 💀

6. Reporting 📝

this section spells out the specific reporting requirements, motivated by the generic requirements of Section 3.4 ✨

6.1. Mandatory Contents of Packet Reports: Basic Reports 🎀

okay the non-negotiables for Packet Reports are:

  • (i) the input sequence number(s) of any Selectors that acted on the packet in the instance of a Metering Process that produced the report.
  • (ii) the identifier of the Metering Process that produced the selected packet.

the Metering Process must support including the following in each Packet Report, as a configurable option:

  • (iii) a basic report on the packet, i.e., some number of contiguous bytes from the start of the packet, including the packet header (which includes network layer and any encapsulation headers) and some subsequent bytes of the packet payload 📦

some devices may not have the resource capacity or functionality to give more detailed Packet Reports than (i), (ii), and (iii) above 🫠 with this minimum, the Metering Process puts the burden of interpretation on the Collector or on the applications it supplies. some devices may have the capability to provide extended Packet Reports, which the next section covers 🧚

6.2. Extended Packet Reports 💜

the Metering Process may support including the following information in Packet Reports, and including any or all of it is configurable as an option 🌈

  • (iv) fields relating to the following protocols used in the packet: IPv4, IPV6, transport protocols, and encapsulation protocols including MPLS.
  • (v) packet treatment, including:
    • identifiers for any input and output interfaces of the Observation Point that were traversed by the packet
    • source and destination BGP AS
  • (vi) Selection State associated with the packet, including:
    • the timestamp of observation of the packet at the Observation Point. the timestamp should be reported to microsecond resolution ⏱️
    • hash values, where calculated 🔥

it's envisaged that picking fields for Extended Packet Reporting may be used to reduce reporting bandwidth. in that case, the option to report the information in (iii) may not be exercised 🫶

6.3. Extended Packet Reports in the Presence of IPFIX 🦋

if an IPFIX Metering Process is supported at the Observation Point, then in order to be PSAMP compliant, Extended Packet Reports must be able to include all fields required in the IPFIX information model [RFC5102], with modifications appropriate to reporting on single packets rather than Flows 📚 bestie this is the "be compatible or be left out" rule 😤

6.4. Report Interpretation 🔍

the Report Interpretation must include:

  • (i) configuration parameters of the Selectors of the packets reported on
  • (ii) format of the Packet Report
  • (iii) indication of the inherent accuracy of the reported quantities, e.g., of the packet timestamp

the accuracy measure in (iii) is of fundamental importance for estimating the likely error attached to estimates that applications form from the Packet Reports 📊 no accuracy, no trust, periodt 💅

the requirements for robustness and transparency are the reasons Report Interpretation gets included in the Report Stream: it makes the Report Stream self-defining 🪞 the PSAMP framework doesn't rely on an alternative model where interpretation is recovered out of band. that approach isn't robust to undocumented changes in Selector configuration, and it could cause future architectural headaches for network management systems trying to coherently manage both configuration and data collection 😵‍💫

it's not envisaged that all Report Interpretation goes into every Packet Report 🙅‍♀️ a lot of the quantities listed above are expected to be pretty static. they could be communicated periodically, and whenever they change ✨

7. Parallel Metering Processes 🧁

because there are more and more distinct measurement applications with different requirements, it's desirable to set up parallel Metering Processes on a given Observed Packet Stream 🌸 a device that can host a Metering Process should be able to support more than one independently configurable Metering Process at the same time. each of those Metering Processes should have the option of being equipped with its own Exporting Process. otherwise, the parallel Metering Processes may share the same Exporting Process 🤝

each of the parallel Metering Processes should be independent 💜 however, resource constraints may prevent complete reporting on a packet that was selected by multiple Selection Processes. in that case, reporting for the packet must be complete for at least one Metering Process. the other Metering Processes only need to record that they selected the packet, e.g., by incrementing a counter 🔢 the priority among Metering Processes under resource contention should be configurable 👑

it is not proposed to standardize the number of parallel Metering Processes 🙅‍♀️

8. Exporting Process 🚀

this section spells out the specific requirements for the Exporting Process, motivated by the generic requirements of Section 3.6 ✨

8.1. Use of IPFIX 📦

PSAMP will use the IP Flow Information Export (IPFIX) protocol for export of the Report Stream 💖 IPFIX is well suited for this because the IPFIX architecture matches the PSAMP architecture really well, and the means IPFIX provides are sufficient for PSAMP purposes 🎀 on the other hand, not all IPFIX features will need to be implemented by some PSAMP Devices. for example, a device that only offers content-independent Sampling and basic PSAMP reporting has no need to support IPFIX capabilities based on packet fields 🫠

8.2. Export Packets 📬

Export Packets may contain one or more Packet Reports, and/or Report Interpretation. Export Packets must also contain:

  • (i) an identifier for the Exporting Process
  • (ii) an Export Packet sequence number

the Export Packet sequence number lets the Collector spot loss of Export Packets in transit 🕵️‍♀️ fyi some transport protocols, e.g., UDP, don't provide sequence numbers, so this is one of those "it's giving backup plan" moments 💀 and having sequence numbers at the application level lets the Collector calculate the packet loss rate, which can be used, e.g., to estimate original traffic volumes from Export Packets that reach the Collector 📈 slay 👑

8.3. Congestion-Aware Unreliable Transport ✨

okay bestie, the Report Stream doesn't need reliable export 🫶 Section 5.4 shows that input sequence numbers in packet Selectors mean estimating traffic rates isn't wrecked by export loss. Losing an Export Packet just turns into another form of Sampling. It's a less desirable and less controlled form, but it's still Sampling 😭

Retransmitting lost Export Packets eats extra network resources, though. And having to store unacknowledged data is an impediment to ubiquitous support for PSAMP 💀

To hit the timeliness and congestion avoidance requirements of Section 4.3 together, a congestion-aware unreliable transport protocol may be used 🦋 IPFIX is compatible with this, since it mandates support for the Stream Control Transmission Protocol (SCTP) [RFC4960] and the SCTP Partial Reliability Extension [RFC3758]. Iconic 👑

IPFIX also allows the User Datagram Protocol (UDP) [RFC0768] 🙈 but it is not a congestion-aware protocol. In that case, the Export Packets must remain wholly within the administrative domains of the operators [RFC5101]. The PSAMP Exporting Process has a configurable export rate limit (see Section 8.4) that can be used to limit the export rate when a congestion-aware transport protocol is not used. The Collector can notice Export Packet loss through missing export sequence numbers, and then it may reconfigure the export rate limit downwards in order to avoid congestion 🌈

8.4. Configurable Export Rate Limit 🌸

The Exporting Process must have an export rate limit, configurable per Exporting Process. This is useful for two reasons:

  • (i) Even without network congestion, the rate of packet selection may exceed the capacity of the Collector to process reports, especially when many Exporting Processes feed a common Collector. Using an Export Rate Limit lets you control the global input rate to the Collector 💅
  • (ii) IPFIX provides export using UDP as the transport protocol in some circumstances. An Export Rate Limit lets you cap the export rate so it matches both path link speeds and the capacity of the Collector 🫶

8.5. Limiting Delay for Export Packets ⏰

Low measurement latency lets the traffic monitoring system be more responsive to real-time network events, like quickly spotting sources of congestion. Timeliness is generally a good thing for the devices doing the Sampling, since it minimizes the amount of memory needed to buffer samples 🧚

Keeping the packet dispatching delay small has other benefits too, besides limiting buffer requirements. For many applications, a resolution of 1 second is sufficient. Applications in this category include identifying sources associated with congestion, tracing Denial-of-Service (DoS) attacks through the network, and constructing traffic matrices 🔥 Also, keeping dispatch delay within the resolution that applications need means you don't need timestamping by synchronized clocks at Observation Points. You also don't need Observation Points and the Collector to maintain bidirectional communication to track clock offsets 🙌 The Collector can simply process Packet Reports in the order they arrive, using its own clock as a "global" time base. That avoids the complexity of buffering and reordering samples. See [DuGeGr02] for an example 🍓

The delay between observing a packet and transmitting an Export Packet containing a report on that packet has several components. It's hard to standardize a specific numerical delay requirement, since in practice the delay may depend on processor load at the Observation Point. So PSAMP aims to control the part of the delay within the Observation Point that comes from buffering while Export Packets are formed and transmitted 💜

To limit delay in forming Export Packets, the Exporting Process must provide the ability to close out and enqueue for transmission any Export Packet during formation, as soon as it includes one Packet Report ⚡

To limit the delay in transmitting Export Packets, a configurable upper bound on how long an Export Packet can wait before transmission must be provided. If the bound is exceeded, the Export Packet is dropped. This functionality can be provided by the timed reliability service of the SCTP Partial Reliability Extension [RFC3758] 😤

The Exporting Process may enqueue the Report Stream so it can export multiple Packet Reports in a single Export Packet. Any resulting delay must still allow Packet Reports to be available on time, as just described. The timed reliability service of the SCTP Partial Reliability Extension [RFC3758] lets packets get dropped from the export buffer once their age in the buffer goes past a configurable bound. A suitable default value for that bound should be used, so that misconfiguration doesn't cause a low transmission rate 🌷

8.6. Export Packet Compression 🗜️

To conserve network bandwidth and resources at the Collector, Export Packets may be compressed before export. Compression is expected to work quite well, since the selected packets may share many fields in common. For example, that happens when a filter focuses on packets with certain values in particular header fields 🤩 Compression can impact the timeliness of Packet Reports, though. Any resulting delay must not violate the timeliness requirement for making Packet Reports available at the Collector 🥺

8.7. Collector Destination 📍

When exporting to a remote Collector, the Collector is identified by IP address, transport protocol, and transport port number 🗺️

8.8. Local Export 🏠

The Report Stream may be exported directly to on-board measurement-based applications, like ones that form composite statistics from more than one packet. Local Export can be presented through an interface directly to higher-level applications, meaning through an API, instead of using the transport used for off-board export. Specifying such an API is outside the scope of the PSAMP framework 🙅‍♀️

One possible example of Local Export: packets selected by the PSAMP Metering Process serve as input for the IPFIX protocol, which then forms Flow Records out of the stream of selected packets 💖

9. Configuration and Management 🎀

A key requirement for PSAMP is easy reconfiguration of the parameters of the Metering Process, including those for selection and Packet Reports, and of the Exporting Process. A big example is supporting measurement-based applications that want to adaptively drill down on traffic detail in real time 🔍

To make retrieving and monitoring parameters easier, they are to reside in a Management Information Base (MIB). Mandatory monitoring objects will cover all mandatory PSAMP functionality. Alarming on specific parameters could be triggered with thresholding mechanisms, such as the RMON (Remote Network Monitoring) event and alarm [RFC2819] or the event MIB [RFC2981] 🚨

For configuring parameters of the Metering Process, there are several alternatives, including a MIB module with writeable objects and other configuration protocols. For configuring parameters of the Exporting Process, the Packet Report, and the Report Interpretation (which is an IFPIX task), the IPFIX configuration method(s) should be used 🛠️

Although management and configuration of Collectors is out of scope, a PSAMP Device inherits from IPFIX the capability to detect and recover from Collector failure, to the extent that it employs IPFIX as an export protocol. See Section 8.2 of [RFC5470] 🫡

10. Feasibility and Complexity 💅

For PSAMP to be supported across the entire spectrum of networking equipment, it must be simple and inexpensive to implement. You can picture easy-to-implement instances of the mechanisms described in this document. So for that subset of instances, it should be straightforward for virtually all system vendors to include them in their products. Honestly, Sampling and Filtering operations are already realized in available equipment 🌟

Here we give some specific arguments to demonstrate feasibility and comment on the complexity of hardware implementations. We stress that the point of these arguments is not to favor or recommend any particular implementation, or to suggest a path for standardization. The point is to show that the set of possible implementations is not empty 🧠

10.1. Feasibility 🌈

10.1.1. Filtering 🧹

Filtering consists of a small number of mask (bit-wise logical), comparison, and range (greater than) operations. Implementing at least a small number of such operations is straightforward. For example, filters for security Access Control Lists (ACLs) are widely implemented. This could be as simple as an exact match on certain fields, or it could involve more complex comparisons and ranges 🔐

10.1.2. Sampling 🎲

Sampling based on either counters (counter set, decrement, test for equal to zero) or range matching on the hash of a packet (greater than) is possible given a small number of Selectors. There may be some differences in ease of implementation for hardware vs. software platforms 🦾

10.1.3. Hashing 🪄

Hashing functions vary greatly in complexity. Running a small number of sufficiently simple hash functions is implementable at line rate. For the input to the hash function, hop-invariant IP header fields (IP address, IP identification) and TCP/UDP header fields (port numbers, TCP sequence number) drawn from the first 40 bytes of the packet have been found to have considerable variability; see [DuGr01] 📊

10.1.4. Reporting 📝

The simplest Packet Report would duplicate the first n bytes of the packet. However, such an uncompressed format may tax the bandwidth available to the Exporting Process for high Sampling rates. Reporting selected fields would save on this bandwidth. So there is a trade-off between simplicity and bandwidth limitations ⚖️

10.1.5. Exporting 🚀

Ease of exporting Export Packets depends on the system architecture. Most systems should be able to support export by inserting Export Packets, even through the software path 💌

10.2. Potential Hardware Complexity 🔧✨

okay so bestie, getting low constants for performance while keeping hardware resources small is a real challenge 😭, especially at very high clock frequencies. BUT most of the Selectors are super basic and their implementations are very well understood 💅. The average Application-Specific Integrated Circuit (ASIC) designer just grabs canned library instances of these operations instead of designing them from scratch 🫶. Plus, networking equipment generally doesn't need to run at the fastest clock rates, so getting reasonably efficient implementations takes way less effort 🌸.

Simple bit-wise logical operations are easy to build in hardware 🔥. Operations like NAND, NOR, and XNOR translate directly to four-transistor gates. Each bit of a multiple-bit logical operation is completely independent, so they can all run in parallel with no extra performance cost above a single-bit operation 🦋.

Comparisons (EQ/NEQ) take O(log(M)) stages of logic, where M is the number of bits involved in the comparison. The log(M) part is needed to accumulate the result into a single bit 🧮.

Greater-than operations, the ones used to figure out whether a hash falls in a selection range, are basically a determination of the most significant not-equivalent bit in the two operands. The operand with that most-significant-not-equal bit set to one is the greater one 👑.

So a greater-than operation is also an O(log(M)) stages-of-logic operation 💜. Optimized implementations of arithmetic operations are also O(log(M)), thanks to propagation of the carry bit.

Setting a counter is simply loading a register with a state. That's simple and fast, O(1) 🚀. Incrementing or decrementing a counter is a read, followed by an arithmetic operation, followed by a store. Making the register dual-ported does take additional space, but it's a well-understood technique. So the increment/decrement is also an O(log(M)) operation 🌈.

Hashing functions come in a variety of forms 🧚. The computation involved in a standard Cyclic Redundancy Check (CRC), for example, is essentially a set of XOR operations, where the intermediate result is stored and XORed with the next chunk of data. There are only O(1) operations and no log complexity operations. So a simple hash function, such as CRC or generalizations thereof, can be implemented in hardware very efficiently ✨.

At the other end of the complexity range, the MD5 function uses a large number of bit-wise conditional operations and arithmetic operations. The former are O(1) operations and the latter are O(log(M)) 🙈. MD5 specifies 256 32 bit ADD operations per 16 bytes of input processed. Consider processing 10 Gb/sec at 100 MHz (this processing rate appears to be currently available). That requires processing 12.5 bytes/cycle, and hence at least 200 adders, which is a sizeable number 💀. Because of data dependencies within the MD5 algorithm, the adders cannot simply run in parallel, so you'd need either faster clock rates and/or more advanced architectures. Thus, selection hashing functions as complex as MD5 may be precluded for ubiquitous use at full line rate 😬. This motivates exploring selection hash functions with complexity somewhere between that of MD5 and CRC 🍓. In some applications (see Section 11), a second hash may be calculated on only selected packets. MD5 is feasible for this purpose if the rate of production of selected packets is sufficiently low 🫶.

11. Applications 🎀

We first describe several representative operational applications that require traffic measurements at various levels of temporal and spatial granularity 📊. Some of the goals here appear similar to those of IPFIX, at least in the broad classes of applications supported. The major benefit of PSAMP is the support of new network management applications, specifically, those enabled by the packet Selectors that it supports 👑.

11.1. Baseline Measurement and Drill Down

Packet Sampling is ideally suited to determine the composition of the traffic across a network 🔍. The approach is to enable measurement on a cut-set of the network links such that each packet entering the network is seen at least once, for example, on all ingress links. Unfiltered Sampling with a relatively low selection fraction establishes baseline measurements of the network traffic 🌸. Packet Reports include packet attributes of common interest: source and destination address and port numbers, prefix, protocol number, type of service, etc. Traffic matrices are indicated by reporting source and destination AS matrices. Absolute traffic volumes are estimated by renormalizing the sampled traffic volumes through division by either the Configured Selection Fraction or the Attained Selection Fraction (as derived from input packet counters included in the Report Stream) 🧾.

Suppose an operator or a measurement-based application detects an interesting subset of a Packet Stream, as identified by a particular packet attribute 👀. Real-time drill down to that subset is achieved by instantiating a new Metering Process on the same Observed Packet Stream from which the subset was reported. The Selection Process of the new Metering Process filters according to the attribute of interest, and composes with Sampling if necessary to manage the attained fraction of packets selected 🎯.

11.2. Trajectory Sampling

The goal of trajectory Sampling is the selection of a subset of packets at all enabled Observation Points at which these packets are observed in a network domain 🦋. Thus, the selection decisions are consistent in the sense that each packet is selected either at all enabled Observation Points or at none of them. Trajectory Sampling is realized by Hash-based Selection if all enabled Observation Points apply a common hash function to a portion of the Packet Content that is invariant along the packet path. (Thus, fields such as TTL and CRC are excluded.) 🙃

The trajectory followed by a packet is reconstructed from Packet Reports on it that reach the Collector 🗺️. Reports on a given packet are associated by matching either a label comprising the invariant reported Packet Content or possibly some digest of it. The reconstruction of trajectories and methods for dealing with possible ambiguities due to label collisions (identical labels reported by different packets) and potential loss of reports in transmission are dealt with in [DuGr01], [DuGeGr02], and [DuGr04] 📚.

11.3. Passive Performance Measurement

Trajectory Sampling enables the tracking of the performance experience by customer traffic, with customers identified by a list of source or destination prefixes, or by ingress or egress interfaces 💖. Operational uses include the verification of Service Level Agreements (SLAs), and troubleshooting following a customer complaint 🧐.

In this application, trajectory Sampling is enabled at all network ingress and egress interfaces. Rates of loss in transit between ingress and egress are estimated from the proportion of trajectories for which no egress report is received 📉. Note that loss of customer packets is distinguishable from loss of Packet Reports through use of report sequence numbers 🔢. Assuming synchronization of clocks between different entities, delay of customer traffic across the network may also be measured; see [Zs02] ⏱️.

Extending hash selection to all interfaces in the network would enable attribution of poor performance to individual network links 🕵️‍♀️.

11.4. Troubleshooting

PSAMP Packet Reports can also be used to diagnose problems whose occurrence is evident from aggregate statistics, such as per interface utilization and packet loss statistics 🩺. These statistics are typically moving averages over relatively long time windows, e.g., 5 minutes, and serve as a coarse-grain indication of the operational health of the network. The most common method of obtaining such measurements is through the appropriate SNMP MIBs (MIB-II [RFC1213] and vendor-specific MIBs) 📟.

Suppose an operator detects a link that is persistently overloaded and experiences significant packet drop rates 🚨. There is a wide range of potential causes: routing parameters (e.g., OSPF link weights) that are poorly adapted to the traffic matrix, e.g., because of a shift in that matrix; a DoS attack, a flash crowd, or a routing problem (link flapping). In most cases, aggregate link statistics are not sufficient to distinguish between such causes and to decide on an appropriate corrective action 🤷‍♀️. For example, if routing over two links is unstable, and the links flap between being overloaded and inactive, this might be averaged out in a 5-minute window, indicating moderate loads on both links 🙃.

Baseline PSAMP measurement of the congested link, as described in Section 11.1, enables measurements that are fine grained in both space and time 🔬. The operator has to be able to determine how many bytes/packets are generated for each source/destination address, port number, and prefix, or other attributes, such as protocol number, MPLS forwarding equivalence class (FEC), type of service, etc. This allows the precise determination of the nature of the offending traffic 🎯. For example, in the case of a Distributed Denial of Service (DDoS) attack, the operator would see a significant fraction of traffic with an identical destination address 🚩.

In certain circumstances, precise information about the spatial flow of traffic through the network domain is required to detect and diagnose problems and verify correct network behavior 🧭. In the case of the overloaded link, it would be very helpful to know the precise set of paths that packets traversing this link follow. This would readily reveal a routing problem such as a loop, or a link with a misconfigured weight 🔁. More generally, complex diagnosis scenarios can benefit from measurement of traffic intensities (and other attributes) over a set of paths that is constrained in some way. For example, if a multihomed customer complains about performance problems on one of the access links from a particular source address prefix, the operator should be able to examine in detail the traffic from that source prefix that also traverses the specified access link towards the customer 💅.

While it is in principle possible to obtain the spatial flow of traffic through auxiliary network state information, e.g., by downloading routing and forwarding tables from routers, this information is often unreliable, outdated, voluminous, and contingent on a network model 🙄. For operational purposes, a direct observation of traffic flow provided by trajectory Sampling is more reliable, as it does not depend on any such auxiliary information 💜. For example, if there was a bug in a router's software, direct observation would allow the diagnosis of the effect of this bug, while an indirect method would not 🐛.

12. Security Considerations 🔒

12.1. Relation of PSAMP and IPFIX Security for Exporting Process

⚠️ Security is serious business, bestie! Read this part carefully.

As detailed in Section 4.3, PSAMP shares with IPFIX security requirements for export, namely, confidentiality, integrity, and authenticity of the exported data; see also Sections 6.3 and 10 of [RFC3917]. Since PSAMP will use IPFIX for export, it can employ the IPFIX protocol [RFC5101] to meet its requirements 🛡️✨.

12.2. PSAMP Specific Privacy Considerations 🎀

Okay so, the difference from IPFIX is that a PSAMP Device can, in some setups, report the first few bytes of a packet, and those bytes might include a bit of the payload 👀 This is still okay under [RFC2804] because nothing forces you to capture an entire Packet Stream of a Flow. A unit Sampling rate (1 in 1 Sampling) is NOT REQUIRED by the PSAMP protocol, and neither is reporting a specific number of initial bytes. Phew 💅

Privacy is a big deal here 🫶 The contents of the Packet Reports MUST be able to stay confidential in transit between the exporting PSAMP Device and the Collector, so that anyone using the observed traffic as a sender or receiver stays protected. PSAMP will use IPFIX as the exporting protocol, and the IPFIX protocol MUST provide mechanisms to keep the Exporting Process confidential, for example encrypting the Export Packets [RFC5101] 🔐✨

12.3. Security Considerations for Hash-Based Selection 🦋

12.3.1. Modes and Impact of Vulnerabilities

Here's the scary part 😭 A big worry with Hash-based Selection is that some large group of related packets could get sampled way more than it should, either:

(i) through unanticipated behavior in the hash function, or

(ii) because the packets had been deliberately crafted to have
     this property.

Only cryptographic hash functions (for example, one based on MD5) that use a private parameter are strong enough to survive the attacks we can imagine 🛡️ BUT implementation considerations might mean the strongest hash functions can't run at line rate 💀 So PSAMP isn't expected to standardize on a cryptographic hash function right now. This section is here to help folks talk through the vulnerabilities and trade-offs of different hash function choices. [RFC5475] goes into way more detail in Section 6.2.2 of [RFC5475] 📚

An attacker who can predict Sampling outcomes could build a Packet Stream that dodges selection, or another that makes the measurement infrastructure select every single one of its packets 🙈 They might do this by knowing the hash function. They could also reverse engineer the hash function's parameters by watching which packets from a known Packet Stream get selected. That info could come from billing data, how intrusion detection systems react, or watching a Report Stream.

Hash-based Selection is deterministic, so it's open to replay attacks 🔁 Sending the same packet over and over might be noticed by other measurement methods, like collecting Flow statistics. A bunch of distinct packets that look statistically like normal traffic would probably be harder to spot. Changing the hash function parameters again and again can help soften replay attacks.

12.3.2. Use of Private Parameters in Hash Functions

Hash functions for Hash-based Selection are going to be standardized, which means they're public 👀 So the packet selection decision MUST be controlled by some private quantity tied to the Hash-based Selection Selector. Keeping the range of selected hash values private is NOT enough on its own to stop an attacker from crafting a stream of distinct packets that gets over-selected 🙅‍♀️ A private parameter MUST be used inside the hash function. For example, that could be a private modulus, or the hash input could be concatenated with a private string before hashing 🔑

12.3.3. Strength of Hash Functions

The exact hash function you pick, and how you use it, decides what kinds of vulnerabilities you're dealing with 🧐

  • Cryptographic hash functions: when a private parameter is used, future selection outcomes cannot be predicted even by an attacker who knows past selection outcomes. 🔒
  • Non-cryptographic hash functions:
    • Using knowledge of past selection outcomes: some well-known hash functions, e.g., CRC-32, are vulnerable to attacks, in the sense that their private parameter can be determined with knowledge of sufficiently many past selections, even when a private parameter is used; see [GoRe07]. 😬
    • No knowledge of past selection outcomes: using a private parameter hardened the hash function to classes of attacks that work when the parameter is public, although vulnerability to future attacks is not precluded. 🧱

12.4. Security Guidelines for Configuring PSAMP 🔐

Hash function parameters configured in a PSAMP Device are sensitive info, so they MUST be kept private 🤫 Attackers can use probing techniques to find the parameters of non-cryptographic hash functions, as mentioned above. Implementation and procedural weaknesses can also let them find parameters, no matter what class of hash function you're using. These measures may help stop that from happening:

Hash function parameters MUST NOT be displayable in cleartext on PSAMP Devices. That cuts down the chance of someone finding them through unauthorized access to the device 🚫

Hash function parameters MUST NOT be remotely set in cleartext over a channel that may be eavesdropped. 👂🚫

Hash function parameters MUST be changed regularly. Those changes MUST be synchronized across all PSAMP Devices in a domain where trajectory Sampling is used, so Sampling of packets stays consistent over the whole domain 🔄✨

Default hash function parameter values SHOULD be initialized randomly, so attackers can't exploit predictable values 🎲

13. Contributors 🌸

Sharon Goldberg contributed to Section 12.3 on security considerations for Hash-based Selection. She's the real MVP 👑

Sharon Goldberg
Department of Electrical Engineering
Princeton University
F210-K EQuad
Princeton, NJ 08544
USA
EMail: goldbe@princeton.edu

14. Acknowledgments 💜

The authors would like to thank Peram Marimuthu and Ganesh Sadasivan for their input in early working drafts of this document. Thank you, queens 🫶

15. References 📚

15.1. Normative References

[RFC5476]  Claise. B., Ed., "Packet Sampling (PSAMP) Protocol
           Specifications", RFC 5476, March 2009.

[RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
           Carle, "Information Model for Packet Sampling Exports",
           RFC 5477, March 2009.

[RFC5101]  Claise, B., Ed., "Specification of the IP Flow Information
           Export (IPFIX) Protocol for the Exchange of IP Traffic
           Flow Information", RFC 5101, January 2008.

[RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
           1981.

[RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
           Meyer, "Information Model for IP Flow Information Export",
           RFC 5102, January 2008.

[RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
           RFC 4960, September 2007.

[RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
           Conrad, "Stream Control Transmission Protocol (SCTP)
           Partial Reliability Extension", RFC 3758, May 2004.

[RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
           Raspall, " Sampling and Filtering Techniques for IP Packet
           Selection", RFC 5475, March 2009.

15.2. Informative References

[RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
           Networks", BCP 84, RFC 3704, March 2004.

[RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
           Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
           Functional Specification", RFC 2205, September 1997.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998.

[DuGeGr02] N.G. Duffield, A. Gerber, M. Grossglauser, "Trajectory
           Engine: A Backend for Trajectory Sampling", IEEE Network
           Operations and Management Symposium 2002, Florence, Italy,
           April 15-19, 2002.

[DuGr04]   N. G. Duffield and M. Grossglauser, "Trajectory Sampling
           with Unreliable Reporting", Proc IEEE Infocom 2004, Hong
           Kong, March 2004.

[DuGr08]   N. G. Duffield and M. Grossglauser, "Trajectory Sampling
           with Unreliable Reporting", IEEE/ACM Trans. on Networking,
           16(1), February 2008.

[RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41, RFC
           2914, September 2000.

[GoRe07]   S. Goldberg, J. Rexford, "Security Vulnerabilities and
           Solutions for Packet Sampling", IEEE Sarnoff Symposium,
           Princeton, NJ, May 2007.

[RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May
           2000.

[RFC2981]  Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000.

[RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
           for Network Management of TCP/IP-based internets:MIB-II",
           STD 17, RFC 1213, March 1991.

[RFC3176]  Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's
           sFlow: A Method for Monitoring Traffic in Switched and
           Routed Networks", RFC 3176, September 2001.

[RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
           "Framework for IP Performance Metrics", RFC 2330, May
           1998.

[RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
           August 1980.

[RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
           "Requirements for IP Flow Information Export (IPFIX)", RFC
           3917, October 2004.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
           2006.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031, January 2001.

[RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
           "Architecture for IP Flow Information Export", RFC 5470,
           March 2009.

[RFC2819]  Waldbusser, S., "Remote Network Monitoring Management
           Information Base", STD 59, RFC 2819, May 2000.

[Zs02]     T. Zseby, "Deployment of Sampling Methods for SLA
           Validation with Non-Intrusive Measurements", Proceedings
           of Passive and Active Measurement Workshop (PAM 2002),
           Fort Collins, CO, USA, March 25-26, 2002.

Authors' Addresses 🦋

Derek Chiou
Department of Electrical and Computer Engineering
University of Texas at Austin
1 University Station, Stop C0803, ENS Building room 135,
Austin TX, 78712
USA

Phone: +1 512 232 7722
EMail: Derek@ece.utexas.edu
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium

Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Nick Duffield, Editor
AT&T Labs - Research
Room B139
180 Park Ave
Florham Park NJ 07932
USA

Phone: +1 973-360-8726
EMail: duffield@research.att.com
Albert Greenberg
One Microsoft Way
Redmond, WA 98052-6399
USA

Phone: +1 425-722-8870
EMail: albert@microsoft.com
Matthias Grossglauser
School of Computer and Communication Sciences
EPFL
1015 Lausanne
Switzerland

EMail: matthias.grossglauser@epfl.ch
Jennifer Rexford
Department of Computer Science
Princeton University
35 Olden Street
Princeton, NJ 08540-5233
USA

Phone: +1 609-258-5182
EMail: jrex@cs.princeton.edu
📦 where this page comes from