[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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.

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



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.




--
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/>