Subject: some comments on draft-ietf-psamp-framework-09.txt

From: Derek Chiou <[email-masked]>
Date: Sun, 14 Nov 2004 18:06:27 -0500

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
***************
*** 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.
        
***************
*** 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
***************
*** 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. 
***************
*** 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.

***************
*** 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.
***************
*** 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?
     
***************
*** 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
***************
*** 1239,1240 ****
--- 1243,1247 ----
        the buffer exceeds a configurable bound.
+
+       COLLECTOR MAY SEE VERY LOW SAMPLED PACKET RATES BECAUSE OF
+       MISCONFIGURATION 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.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Matthias Grossglauser <[email-masked]>
Date: Mon, 22 Nov 2004 19:06:51 +0100

Folks,

I think the document is in very good shape. A few comments below. I will 
send a list of minor typos directly to the editor.

Matt

>- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency".
>Also, the term "non-contingency" seems a bit strange.
>  
>
A good term might be "causality".

Regarding the discussion of "attacks" against hash-based PSAMP by 
crafting packets, let me refer back to a comment a made a while ago:

https://www.psg.com/lists/psamp/psamp.2002/msg00170.html

Basically, if the attacker does not know which hash function in the 
family is active, then this provides *stronger* protection than if the 
attacker knows the hash function, but not the range it has to fall into 
to get sampled. This might be worth pointing out. It is alluded to the 
in draft by saying that there can be a family of hash functions, but it 
could perhaps be strengthened by pointing out that this provides 
additional robustness against crafted packets.

>Since an export packet may contain multiple packet reports, the export
>process id can be included once per export packet.
>
>  
>
Did we say anywhere that exporting process IDs are included? Note that 
this is important to enable the collector to estimate the Export Packet 
drop rate under unreliable transport to drive a congestion-control 
algorithm; the finer per-report IDs are not necessarily sufficient for 
this, I think. Of course, in most situations the underlying unreliable 
transport protocol would have sequence numbers already, but it might be 
desirable to have a transport-independent EP numbering for layer 
independence.

>How about:
>
>Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access routing state at line rate. However, when filtering follows sampling in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently slow that the filter could select based on routing state.
>
The thinning could have happened through another filter also (e.g., 
based on a packet field), couldn't it? So perhaps we should not limit it 
to sampling. How about "However, if in a Composite Selector, filtering 
based on routing state is preceded by at least one other Selector, the 
rate of the input to that filter may be...".

>In order to limit delay in the formation of Export Packets, the 
>      Exporting Process must provide the ability to close out and 
>      enqueue for transmission any Export Packet during formation as 
>      soon as it includes one Packet Report.  
>
It may make sense to allow for an Export Packet to be generated even if 
there are ZERO Packet Reports pending, for this EP to act as a heartbeat 
packet to signal to the collector that connectivity is ok. This would 
allow the collector to distinguish between an absence of traffic at the 
PSAMP device and loss of connectivity.