Subject: Re: [Gen-art] Gen-ART review of draft-ietf-psamp-framework-12

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Apr 2008 14:10:11 -0500

Apologies for the delayed response.

The proposed security considerations language address my concerns  
about that section. All of my other concerns were addressed in  
previous email exchanges.

Thanks!

Ben.

On Mar 14, 2008, at 9:20 AM, DUFFIELD, NICHOLAS G (NICK) wrote:
>
> 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-masked]]
>> 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-masked]]
>> 		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-masked]
https://www.ietf.org/mailman/listinfo/gen-art