Dan, Ben, Here are the proposed changes to the PSAMP framework in response to your review items that we not previously addressed. Please let me know whether these address your comments.
Nick --- > From: Romascanu, Dan (Dan) [mailto:[EMAIL PROTECTED] > E7: the list of filters for the Selection Process in Section 5.2, page > 15: What do (iv) and (v) mean? Are these packets that failed Ingress > filtering as per RFC2827 (iv) and packets that were detected as out of > spec for (v)? Making this clear would help. PROPOSED: new versions of item (iv) and (v): (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 (RSVP). Packets that match the Failed Resource Reservation condition are packets that do not fulfill the RSVP specification as defined in [RCF2205]. > E5: Section 4.2 - what means 'cognizant of privacy and anonymity > issues'? [...] PROPOSED change OLD: Privacy: selection of the content of Packet Reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with [RFC-2804]. Full packet capture of arbitrary packet streams is explicitly out of scope. NEW: Privacy: although selection of the content of Packet Reports must be responsive to the needs of measurement applications, it must also conform to [RFC-2804]. In particular, full packet capture of arbitrary packet streams is explicitly out of scope. > T5: Section 12 Security Considerations - this section seems to me > incomplete. For example RFC 3917 describes in its corresponding Security > Considerations section the need to deal with the DoS and forgery > threats. Similar information should be included here at least by > reference - e.g. the need of authenticating collectors, protect against > mis-configuration of the metering and reporting processes, etc. > From: Ben Campbell [mailto:[EMAIL PROTECTED] > Section 12: Security Considerations > > The security consideration section seems too lightweight. It > simply calls out some security related requirements elsewhere in the > document, and offers no additional discussion. It is not clear to me that > the referenced sections described the requirements from a security > perspective--it would be useful to describe in section 12 _why_ those > requirements are important for security, and what potential security > issues or attacks they are intended to prevent. > > More importantly, PSAMP seems to me to have lots of privacy > implications, which the PSAMP charter appears to acknowledge with its > mention of privacy and anonymity issues. In my opinion these warrant > discussion in this section. Here is the proposed replacement for Section 12, now enlarged. 12. Security Considerations 12.1 Relation of PSAMP and IPFIX Security for Exporting Process 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 [RFC-3917]. Since PSAMP will use IPFIX for export, it can employ the IPFIX protocol [RFC-5101] to meet its requirements. 12.2 PSAMP Specific Privacy Considerations In distinction with IPFIX, a PSAMP device may, in some configurations, report some number of initial bytes of the packet, which may include some part of a packet payload. This option is conformant with the requirements of [RFC-2804] since it does not mandate configurations that would enable capture of an entire packet stream of a flow: neither a unit sampling rate (1 in 1 sampling) nor reporting a specific number of initial bytes, are required by the PSAMP protocol. To preserve privacy of any users acting as sender or receiver of the observed traffic the contents of the packet reports must be able to remain confidential in transit between the exporting PSAMP device and the collector. PSAMP will use IPFIX as the exporting protocol, and the IPFIX protocol must provide mechanisms to ensure confidentiality of the exporting process, for example, encryption of export packets [RFC-5101]. 12.3 Security Considerations for Hash-Based Selection 12.3.1 Modes and Impact of vulnerabilities A concern for Hash-based Selection is whether some large set of related packets could be disproportionately sampled, either (i) through unanticipated behavior in the Hash Function, or (ii) because the packets had been deliberately crafted to have this property. As detailed below, only cryptographic hash functions (e.g. one based on MD5) employing a private parameter are sufficiently strong to withstand the range of conceivable attacks. However, implementation considerations may preclude operating the strongest hash functions at line rate. For this reason PSAMP is not expected to standardize around a cryptographic hash function at the present time. The purpose of this section is to inform discussion of the vulnerabilities and trade-offs associated with different hash function choices. Section 6.2.2 of [PSAMP-FMWK] does this in more detail If an attacker is able to predict packet sampling outcomes, they could craft a packet stream that could evade selection; or another that could overwhelm the measurement infrastructure with all its packets being selected. An attacker may attempt to do this based on knowledge of the hash function. An attacker could employ knowledge of selection outcomes of a known packet stream to reverse engineer parameters of the hash function. This knowledge could be gathered e.g. from billing information, reactions of intrusion detection systems, or observation of a report stream. Since hash-based selection is deterministic, it is vulnerable to replay attacks. Repetition of a single packet may be noticeable to other measurement methods if employed (e.g. collection of flow statistics), whereas a set of distinct packets that appears statistically similar to regular traffic may be less noticeable. The impact of replay attacks on hash based selection may be mitigated by repeated changing of hash function parameters. . 12.3.2 Use of Private Parameters in Hash Functions Because hash functions for Hash-based selection are to be standardized and hence public, the packet selection decision must be controlled by some private quantity associated with the hash-based Selector. Making private the range of hash values for which packets are selected is not alone sufficient to prevent an attacker crafting a stream of distinct packets that are disproportionately selected. A private parameter must be used within the hash function, for example, a private modulus in a hash function, or by concatenating the hash input with a private string prior to hashing. 12.3.3 Strength of Hash Functions The specific choice of hash function and it usage determines the types of potential vulnerability: * Cryptographic hash functions: when a private parameter is used, selection future outcomes cannot be predicted even by an attacker with knowledge of 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 information, which must be kept private. As well using probing techniques to discover parameters of non-cryptographic hash functions described as described above, implementation and procedural weaknesses may lead to attackers discovering parameters, whatever class of hash function is used. The following measures may prevent this occurring: Hash function parameters must not be displayable in cleartext on PSAMP devices. This reduces the chance for the parameters to be discovered by unauthorized access to the PSAMP device. Hash function parameters must not be remotely set in cleartext over a channel which may be eavesdropped. Hash function parameters must be changed regularly. Note that such changes must be synchronized over all PSAMP devices in a domain under which Trajectory Sampling is employed in order to maintain consistent sampling of packets over the domain. Default hash function parameter values should be initialized randomly, in order to avoid predictable values that attackers could exploit. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
