Paul, I vote for solution number 2. I don't think we need an information element that represents your "knob". The collector needs to have some knowledge about the protocol anyway, so it can decode the data into something useful. So it also should know when the header ends and the payload starts. If it just gets the header bytes its OK. If it gets more then go on... Regards, Thomas Am Freitag, 24. März 2006 03:33 schrieb Paul Aitken: > Dear psampers, > > As I presented in yesterday's PSAMP WG meeting, PSAMP-INFO has one open > > issue which must be solved: > > Should the ipHeaderPacketSection and mplsLabelStackSection also > > report payload contents if the specified section length is longer > > than the IP header or stack size, respectively? > > Actually, it also applies to the dataLinkFrameSection which "carries the > first n octets from the data link frame of a sampled packet." > > - but if sufficient length is specified, does it continue on to also > report the L3 header and even the L3 payload? > > Sometimes capture of some octets of the payload information is very > useful - eg, to capture the UDP/TCP port numbers, or for protocol analysis. > > But in yesterday's WG meeting, it was pointed out that there may be > scenarios where capture of payload information is undesireable and maybe > even illegal. So clearly we need to find a way to control access to the > payload information. > > So below, I present two possible solutions for discussion. Others may be > possible too. > > Please express your opinions immediately so we can resolve and close > this issue. > > Thanks. > > > (1) Use multiple information elements, eg: > > ipPacketSection - IP header, continuing into the payload > ipHeaderPacketSection - IP header only > ipPayloadPacketSection - IP payload only > > dataLinkFrameSection - data link frame, continuing into L3 > dataLinkHeaderFrameSection - data link header only > > mplsPacketSection - MPLS label stack, cont into payload > mplsLabelStackSection - MPLS label stack only > mplsPayloadPacketSection - MPLS payload only > > > - export of the relevant IEs can be ommitted > when access to payload information is undesireable. > > - how can you capture port or protocol information > without knowing some payload bytes? > > > (2) Use the existing information elements, with an application specific > configuration knob controlling whether they continue into the next > section or not: > > ipHeaderPacketSection - IP header, optionally cont into payload > ipPayloadPacketSection - IP payload only > > dataLinkFrameSection - data link frame, continuing into L3 > > mplsLabelStackSection - MPLS label stack, opt cont into payload > mplsPayloadPacketSection - MPLS payload only > > > - how will the exporter report whether or not > the configuration knob is set? With another IE? > > > Regarding the length of packet sections, the common rule (regardless of > the IE definition) is that the exact amount of requested octets must be > exported as was defined in the template (ie, no padding short sections > with zero), else a new template must be sent either with the available > length or using variable length encoding.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature