[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: some comments on draft-ietf-psamp-framework-09.txt
Derek,
Thanks for your comments. See inline:
> -----Original Message-----
> From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
Behalf
> Of Derek Chiou
> Sent: Sunday, November 14, 2004 6:06 PM
> To: psamp@ops.ietf.org
> Subject: some comments on draft-ietf-psamp-framework-09.txt
>
> Hi,
>
> I've reviewed psamp-framework-09. It looks very good overall. I have
> some (mostly very minor) comments that I've listed below.
>
> Thanks.
>
> Derek
>
> *** draft-ietf-psamp-framework-09.txt Sun Nov 14 17:50:05 2004
> --- draft-ietf-psamp-framework-09-derek.txt Sun Nov 14 17:54:11
2004
> ***************
> *** 45,47 ****
> the components of this architecture, then describes some
generic
> ! requirements, motivated the dual aims of ubiquitous deployment
> and utility of the reports for applications. Detailed
> --- 45,47 ----
> the components of this architecture, then describes some
generic
> ! requirements AND MOTIVATES the dual aims of ubiquitous
deployment
> and utility of the reports for applications. Detailed
> ***************
Now reads:
This framework details the components of this architecture, then
describes some generic requirements, motivated by the dual aims of
ubiquitous deployment and utility of the reports for applications.
> *** 174,179 ****
>
> across multivendor domains. This requires domain wide
consistency
> in the types of selection schemes available, the manner in
which
> the resulting measurements are presented, and consequently,
> ! consistency of the interpretation that can be put on them.
>
> --- 174,179 ----
>
> across multivendor domains. This requires domain-wide
consistency
> in the types of selection schemes available, the manner in
which
> the resulting measurements are presented, and consequently,
> ! CONSISTENT INTERPRETATION OF THE MEASUREMENTS.
>
> ***************
Now reads:
This requires domain wide consistency in the types of selection schemes
available, and the manner in which the resulting measurements are
presented and interpreted.
> *** 613,615 ****
>
> ! * Encrypted Packets: Selectors that interpret of packet fields
> must be configurable to ignore (i.e. not select) encrypted
> --- 613,615 ----
>
> ! * Encrypted Packets: Selectors that interpret packet fields
> must be configurable to ignore (i.e. not select) encrypted
> ***************
OK
> *** 778,780 ****
>
> ! * Probabilistic n-out-of-N Sampling: form each count-based
> successive block of N packets, n are selected at random.
> --- 778,780 ----
>
> ! * Probabilistic n-out-of-N Sampling: from each count-based
> successive block of N packets, n are selected at random.
> ***************
OK
> *** 825,829 ****
> applied to a subset of packet content, and the packet is
> ! selected of the resulting hash falls in a specified range.
With
> ! a suitable hash function, hash based selection approximates
> ! uniform random sampling. Applications of hash-based sampling
> are described in Section 11.
> --- 825,829 ----
> applied to a subset of packet content, and the packet is
> ! selected if the resulting hash falls in a specified range.
With
> ! a suitable hash function, hash-based selection approximates
> ! uniform random sampling (NOT NECESSARILY). Applications of
> hash-based sampling
> are described in Section 11.
>
> THOUGH IN GENERAL HASH-BASED SELECTION MAY APPROXIMATE UNIFORM RANDOM
> SAMPLING, PACKETS THAT LOOK THE SAME TO THE HASH ARE ALWAYS GOING TO
BE
> TREATED THE SAME AS THE HASH. THUS, A DOS ATTACK THAT KNOWS THE HASH
> CAN ESCAPE DETECTION BY A HASH-BASED SELECTOR BUT CANNOT ESCAPE
> DETECTION BY A UNIFORM RANDOM SAMPLING SELECTOR. I MAY HAVE COMMENTED
> ON THIS BEFORE, BUT I FIGURE I'LL SAY IT AGAIN.
>
Just knowing the hash is not enough. The attacker has to know the
selection range (which could be private) to determine whether the packet
is selected. All this is discussed more in the sampling techniques
draft. So I propose to
Replaced:
"With a suitable hash function, hash-based selection approximates
uniform random sampling."
With:
"The stronger the hash function, the more closely hash-based selection
approximates uniform random sampling. Robustness and security
considerations of hash-based selection are discussed in [PSAMP-TECH]."
> ***************
> *** 959,962 ****
> the Attained Selection Fraction
> !
> ! With Composite Selectors, and input sequence number must be
> reported for each Selector in the composition.
> --- 959,962 ----
> the Attained Selection Fraction
> !
> ! With Composite Selectors, an input sequence number must be
> reported for each Selector in the composition.
OK
> ***************
> *** 1112,1114 ****
> expected to be relatively static; they could be communicated
> ! periodically, and upon change.
>
> --- 1112,1118 ----
> expected to be relatively static; they could be communicated
> ! periodically, and upon change.
> !
> ! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT
> ! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY
> ! PACKET REPORT?
Since an export packet may contain multiple packet reports, the export
process id can be included once per export packet.
>
> ***************
> *** 1172,1174 ****
> In order to jointly satisfy the timeliness and congestion
> ! avoidance requirements of Section 4.3, a congestion aware
> unreliable transport protocol must be used. IPFIX is
compatible
> --- 1176,1178 ----
> In order to jointly satisfy the timeliness and congestion
> ! avoidance requirements of Section 4.3, a congestion-aware
> unreliable transport protocol must be used. IPFIX is
compatible
> ***************
> *** 1178,1180 ****
> User Datagram Protocol (UDP) [UDP] although it is not a
> ! congestion aware protocol. However, in this case, the Export
> Packets must remain wholly within the administrative domains
of
> --- 1182,1184 ----
> User Datagram Protocol (UDP) [UDP] although it is not a
> ! congestion-aware protocol. However, in this case, the Export
> Packets must remain wholly within the administrative domains
of
> ***************
> *** 1194,1196 ****
> category would include: identifying sources associated with
> ! congestion; tracing denial of service attacks through the
network
> and constructing traffic matrices. Furthermore, keeping
dispatch
> --- 1198,1200 ----
> category would include: identifying sources associated with
> ! congestion, tracing denial of service attacks through the
network
> and constructing traffic matrices. Furthermore, keeping
dispatch
> ***************
OK
> *** 1239,1240 ****
> --- 1243,1247 ----
> the buffer exceeds a configurable bound.
> +
> + COLLECTOR MAY SEE VERY LOW SAMPLED PACKET RATES BECAUSE OF
> + MISCONFIGURATION HERE.
>
Can a sensible default value help here?
>
> ***************
> *** 1509,1511 ****
> sampling if necessary to manage the attained fraction of
packets
> ! selected
>
> --- 1517,1519 ----
> sampling if necessary to manage the attained fraction of
packets
> ! selected.
>
>
OK
>
>
> --
> 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/>
--
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/>