Hi Nick,
A couple of in-lined comments.
duffield@research.att.com wrote:
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.
domain-wide
*** 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]."
Do we have to say that a hash approximates uniform random sampling? It
does, most of the time, but it's tough to beat uniform random sampling
and with insider information one could defeat a hash.
***************
*** 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?
Yes.
***************
*** 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/>
|