Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection

[Paul Aitken <paitken@cisco.com>]

Thomas,

> 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'd say that this text says you're not allowed to do that:

      If insufficient octets are available for the length specified in
      the template, the packet section must be sent with a new template
      using either a fixed length Information Element of the necessary
      size or a variable length Information Element.  It's not
      permissible to pad a short packet section to a longer length.

Reasons:

1. "insufficient octets are available" because of a security concern 
(rather than because they simply didn't exist).

2. nulling payload to hide the content is essentially padding out the 
packet section to the necessary length, which is explicitly forbidden by 
the last line.


> I then would propose to use variable length elements by default.

It's definitely necessary if you want to export the packet from the 
start of the IP header to the end of the L4 info to get the port numbers 
(assuming that the header packet section runs right through into the 
payload).


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

You're clearly in favour of solution (2). I also favour this solution.


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

Yes, thanks.

So I propose to adopt solution (2) unless anyone raises serious 
objections by next Friday.

--
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

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