Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection

[Gerhard Muenz <muenz@informatik.uni-tuebingen.de>]

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.

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany
Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220
EMail: muenz@informatik.uni-tuebingen.de
WWW:   http://net.informatik.uni-tuebingen.de/~muenz

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