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

From: "DUFFIELD, NICHOLAS G (NICK)" <[email-masked]>
Date: Fri, 14 Mar 2008 10:20:13 -0400

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