Gerhard and all, I understand now that there are two decisions to take: 1 - do we allow payload in those IEs 2 - how do we encode it So, I guess we all agreed that it may be benefitial in some cases to include payload in those IEs. So the question remains how do I encode it that the collector nows that there is payload and it is the real payload and not something that was just nulled to hide content. I then would propose to use variable length elements by default. It is a local decision of the exporter if it will always export only header bytes or if it will include some bytes of the payload. The local configuration/implementation may impose a maximum limit of those chunks but again thats a design and implementation decision of the exporter. The collector should be able to decide where the header ends and the payload starts (if any payload is in). Paul, I hope this also meets your requirements. Best Regards, Thomas Am Freitag, 24. März 2006 11:02 schrieb Gerhard Muenz: > Dear Thomas, Paul, > > I think Paul's concerns are important. > > Example: > The standard IP header is 20 bytes long, but may be longer with options. > You use a template with ipHeaderPacketSection and length 40 and want to > export an IP packet that has a standard header only. There is payload > which is indicated by the total length in the IP header. > If the monitor now "blanks" the IP payload, your collector does not know > if the payload originally was blank or not. The capability to decode the > IP header information does not help. > > As a third solution, variable length IEs could be used (see > draft-ietf-ipfix-protocol). > > Regards, > Gerhard > > Thomas Dietz wrote: > > 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