Hi,
Here's an idea I had a time ago and I have been building up since
then. Finally (thanks to privilege separation) I believe it's use has
become feasible. And lately, while reading RFC 3611 (RTCP Extended
Reports) I got the final piece I was looking for, so I put down the
idea:
The Idea is a protocol to have sniffing clients and a sniffing servers
communicate. Part like RTSP, and part like RTP+RTCP with
retransmissions.
>From RTSP it takes the session setup mechanism that is, the server
describes its capabilities, the client requests a sniffing session to
be setup, the server tells the client when it's ready an then the
client ask it to start sending.
>From RTCP ER it takes the "Loss RLE Report" mechanism (RFC 3611
section 4.1), that allows a client to tell the server when it missed a
frame, eventually we'll need a flow control mechanism but that comes
later.
The protocol should encode using a TLV format very similar to radius AVPs
Here is how it would work:
The client sends a (multicast?) DISCOVER message.
Listening servers respond with a LISTENING message containing an id
and a random cookie.
With a LOGIN message the client authenticates itself to a server.
- Authenticator: listening_id + md5(cookie+shared_secret).
If authenticated
The server tells the client what it has to offer with a DESCRIBE message:
- which flows (interfaces or stored content) it has
- what version is running
- the plugging it has installed
Upon reception the client might ask the server to SETUP a session
using a certain flow and eventually a display filter and, if the flow
is stored content, when to start/stop replaying it in case the flow
represents an interface a capture filter.
If the server is able to preform the requested session
will respond with a READY message
else
it will respond with an UNABLE message.
At this point the client sends the START message with an eventual
limit (time or volume).
Later we might like to measure the band with available before going ahead.
>From here on we move to the in-flow state.
The server will send FRAME messages whose payload contains
- a frame's data (frame number, timestamps, the payload of the
frame itself and other info)
- the sequence number to ack the latest RR received.
the server might send a NOFRAMES message after every (T1) seconds if
there were no frames to send
the client will periodically (T2) send the server RR (receiver report)
messages, if there's packet loss the client might send them as soon as
a certain loss has happened.
these RR will contain:
- a sequence number for this RR
- chunks reporting arrival/loss similar to those described in RFC
3611 section 4.1
The server will check any RR for lost frames and might resend lost frames.
The client or the server might send an ABORT message with a reason at any time.
these reasons come to my mind:
- server:
too many frames queued up
no RR has been received for N1*T2
administrative request (like a server shutdown)
- client:
user request
unable to recover N2 lost packets after T4
no FRAME or NOFRAMES has being received after N3*T1
It remains to be studied the flow control:
slow down if there is a consistent loss (how much? what consistent is?)
speed up if there's no consistent loss
to do so I'll be writing soon a dissector for it and especially a perl
prototype for the client and the server.
- the perl client will manage the session only (no decoding), the
protocol's data will be "readable" by the dissector.
- the server will probably use tethereal with a ring buffer to read
data from the files just managing the session
That's what I have until now, any ideas?
Any Ideas are welcome.
If we add this feature I believe we would have something worth
$$$$$$... if we only had a poster. :-)
