I agree with Benoit that packet encryption will make general PSAMP difficult, especially since the encryption key will not generally be available.* Flexibility: to support selection of packets using different network protocols or encapsulation layers (e.g. IPv4, IPv6, MPLS, etc), and under packet encryption.
* Secure Export:The situation where this may not be necessary is if the collector and the observation point are not separated by insecure links. For example, if the collector was part of the router that contained the observation points, it's unlikely that security is helpful. Instead, it requires either a general-purpose processor or encryption hardeware, slowing down packet flow or increasing cost/complexity/power if installing hardware.
- confidentiality: the option to encrypt exported data MUST be
provided.
I agree that this would be better as a should rather than a must. Even though it's an option to use it, this could have a significant impact on the design.
I don't agree that uniform pseudorandom sampling may be emulated by hash-based seletion. A DOS attack that knew the hash-based selection method could evade it, but not a pseudorandoming sampling scheme.* Emulated Sampling: selection operations in any of the above four categories may be emulated by operations in the same or another category for the purposes of implementation. For example, uniform pseudorandom sampling may be emulated by hash-based selection, using suitable hash function and hash domain.
7.3 Reliable vs. Unreliable Transport
The export of the report stream does not require reliable export. On the contrary, retransmission of lost measurement packets consumes additional network resources and requires maintenance of state by the export process. As such, the export process would have to be able to receive and process acknowledgments, and to store unacknowledged data. Furthermore, the entity that hosts the export process may not possess its own network address (for example an embedded measurement subsystem in an interface) at which to receive acknowledgments. These requirements would be a significant impediment to having ubiquitous support PSAMP.
Instead, it is proposed that the export process support unreliable export. Sequence numbers on the measurement packets would indicate when loss has occurred, and the analysis of the collected measurement data can account for this loss. In some sense, packet loss becomes another form of sampling (albeit a less desirable, and less controlled, form of sampling).
Since it is proposed that PSAMP use IPFIX as the transport, this suggests that IPFIX MUST support an unreliable transport.
7.6 Congestion-aware Unreliable Transport
Exported measurement traffic competes for resources with other
Internet transfers. Congestion-aware export is important to ensure
that the measurement packets do not overwhelm the capacity of the
network or unduly degrade the performance of other applications,
while making good use of available bandwidth resources.
Choice of transport for PSAMP has to be made under the following constraints:
(i) IESG has mandated that all transport in new protocols must be
congestion aware
(ii) reliable transport is too onerous for general entities that
support PSAMP (see Section 7.3)
(iii) there currently exists no IETF standardized unreliable
congestion-aware transport
In the absence of an existing IETF standardized unreliable
congestion-aware protocol, PSAMP will provisionally nominate the
reliable congestion aware transport protocol TCP as the interim
transport protocol for export. From the preceding arguments, TCP
is unsatisfactory for final standardization in PSAMP.
It's not clear to me that this is the right approach. The alternative is to specify UDP (which is better suited to PSAMP) and agree to move to a suitable congestion aware unreliable transport when one is available. Given that the sampling rate was adapted, as proposed later in the draft, UDP would we a suitable protocol.
7.7.2 Notions of Fairness
In some cases, it may be reasonable to allow the collector to have flexibility in deciding how aggressively to respond to congestion. For example, the exporting entity and the collector may have a very small round-trip time relative to other traffic. Conventional TCP-friendly congestion control would allocate a very large share of the bandwidth to the PSAMP export traffic. Instead, the collector could apply an algorithm that reacts more aggressively to congestion to give a larger share of the bandwidth to other traffic (with larger RTTs).
In other cases, the measurement packets may require a larger share of the bandwidth than other flows. For example, consider a link that carries tens of thousands of flows, including some non TCP-friendly DoS attack traffic. Restricting the PSAMP traffic to a fair share allocation may be too restrictive, and might limit the collection of the data necessary to diagnose the DoS attack which overloads links over which measurement packets are carried. In order to maintain report collection during periods of congestion, PSAMP report streams may claim more than a fair share of link bandwidth, provided the number of report streams in competition with fair sharing traffic is limited. The collector could also employ policies that allocate bandwidth in certain proportions amongst different measurement processes.
Which clearly does not work if TCP rather than UDP is the initial transport protocol.
-- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/psamp/>