Subject: PSAMP: ipHeaderPacketSection and mplsLabelStackSection

From: Paul Aitken <[email-masked]>
Date: Mon, 06 Mar 2006 11:43:38 +0000

Dear psampers,

We have a new open issue in PSAMP-INFO:

   Should the ipHeaderPacketSection and mplsLabelStackSection also
   report payload contents if the specified section length is longer
   than the IP header or stack size, respectively?

ipHeaderPacketSection is currently defined as:

       This information element carries a series of octets from the start
       of the IP header of a sampled packet.

mplsLabelStackSection is currently defined as:

       This information element carries the first n octets from the MPLS
       label stack of a sampled packet.

Potential resolutions include:

(1) We define the behaviour when the requested ipHeaderPacketSection
or mplsLabelStackSectionsection size is larger than the actual amount of
IP header / label stack data available.

   (1a) We define that only IP header / label stack octets are included.

   (1b) We define that the section contains a series of octets starting
        from the beginning of the IP header / label stack and continuing
        through the payload up to the limit of the available data.

(2) We say nothing, and leave it as implimentation defined behaviour.

I believe that allowing these sections to continue into the payload per 
(1b) is potentially the most useful solution.

It saves configuring the capture of seperate header and payload elements 
where capture of the header and first few octets of the payload are 
desired for packet identification and analysis.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Falko Dressler <[email-masked]>
Date: Mon, 06 Mar 2006 19:29:38 +0100

Paul,

this is indeed a difficult issue. At the first look, I was about saying
"yes, 1b) is the best solution because it provides the highest
flexibility". Nevertheless, I fear that many applications will derrive
that allow to monitor packet payload but do not offer to analyze the
packet header, i.e. such monitors are just "remote-pcap-devices". This
is quite fine but makes most of PSAMP functionality (IEs) unnecessary.

1a) is maybe too hard and 2) says "nothing"

so may final answer is either 2) or we need to elaborate a 1c)

Cheers,
Falko

-- 
Dr.-Ing. Falko Dressler
Computer Networks and Communication Systems
University of Erlangen-Nuremberg, Germany
Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409
EMail: [email-masked] / [email-masked]
WWW: http://www7.informatik.uni-erlangen.de/~dressler/

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 07 Mar 2006 10:53:37 +0100

>        label stack of a sampled packet.

Whatever we choose, we should add a few words on this issue in the IE description.

Thanks,

    Juergen
> I believe that allowing these sections to continue into the payload per (1b) is potentially the most useful solution.
>
> It saves configuring the capture of seperate header and payload elements where capture of the header and first few octets of the payload are desired for packet identification and analysis.
>
> --
> Paul Aitken

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 07 Mar 2006 13:57:12 +0000

Hi all

> is quite fine but makes most of PSAMP functionality (IEs) unnecessary.

I agree that 1b is the obvious choice, for the following reasons:

Firstly a PSAMP device offering the ipHeaderPacketSection will not have
to understand how to parse the IP header(s) making the implementation
easier and faster.

Secondly, most people who are using this IE will want to capture all or
part of the TCP/UDP header in order to retrieve the ports etc. and 1b
will allow all this information to be gathered in a single neat packet
section.

On a related note I think we should clearly state that the
ipPayloadPacketSection starts after the IPv6 extension headers to
give consistency between its use for IPv4 and IPv6 packets.

regards

Andrew

---

From: Paul Aitken <[email-masked]>
Date: Fri, 24 Mar 2006 02:33:09 +0000

Dear psampers,

As I presented in yesterday's PSAMP WG meeting, PSAMP-INFO has one open 

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

---

From: Thomas Dietz <[email-masked]>
Date: Fri, 24 Mar 2006 09:44:38 +0100

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

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 24 Mar 2006 11:02:44 +0100

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

-- 
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: [email-masked]
WWW:   http://net.informatik.uni-tuebingen.de/~muenz

---

From: Thomas Dietz <[email-masked]>
Date: Fri, 24 Mar 2006 13:44:17 +0100

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

---

From: Paul Aitken <[email-masked]>
Date: Sat, 25 Mar 2006 16:39:21 +0000

Thomas,

> 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 

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

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

---

From: Paul Aitken <[email-masked]>
Date: Sat, 25 Mar 2006 16:42:11 +0000

Gerhard,

> IP header information does not help.

Blanking the payload is not allowed. See my reply to Thomas.

Instead, the application would have been configured to only export 
header information (no payload info), so it would have to create a new 
template either with the necessary fixed length, or with a variable length.

> draft-ietf-ipfix-protocol).

This is allowed by solution (2).

---

From: Andrew Johnson <[email-masked]>
Date: Mon, 27 Mar 2006 05:53:09 +0100

> template either with the necessary fixed length, or with a variable length.

I think something for implementers to consider, would be to allow a
configurable amount of IP payload in the header packet section.  If
you want the first 8 bytes of payload + all of the IPv4 or IPv6
packet, then you couldn't pick a fixed size to cover all cases
without it being large enough to grab a large part of the payload
in some cases.

regards

Andrew

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 27 Mar 2006 10:17:00 +0200

Paul,

Fine for me. I did not realize that the specification for
ipPayloadPacketSection changed since -03.

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Mon, 27 Mar 2006 11:03:46 +0100

Andrew,

> without it being large enough to grab a large part of the payload

So instead of a boolean [don't]continue-into-payload switch, an 
application could provide a configurable continue-into-payload count of 
n octets, being zero or more depending on the user and legal requirements.

Being an application specific thing, this isn't something for either the 
protocol or info model to dictate. But since we don't have a PSAMP 
Implimentation Guide, I propose these texts:

ipHeaderPacketSection

    Description:

       An application may append zero or more payload octets to the end
       of the ipHeaderPacketSection.

       The size of the exported section may be constrained due to
       limitations in the IPFIX protocol.

mplsLabelStackSection

    Description:

       An application may append zero or more payload octets to the end
       of the mplsLabelStackSection.

       See [RFC3031] for the specification of MPLS packets.
       See [RFC3032] for the specification of the MPLS label stack.

       The size of the exported section may be constrained due to
       limitations in the IPFIX protocol.

---

From: Andrew Johnson <[email-masked]>
Date: Mon, 27 Mar 2006 11:27:26 +0100

Paul,

> n octets, being zero or more depending on the user and legal requirements.

Yes.

> Implimentation Guide, I propose these texts:

Well just because we don't have an implementation guide at the moment,
doesn't mean we won't in the future.  If something is best left to the
implementation guide then I don't think we should have to adjust the
model or protocol documents.

>       of the mplsLabelStackSection.

The wording of this sounds as though it would allow a few octets from the
MPLS stack (not all) then a few octets from the payload.  The previous
description isn't so bad as it doesn't talk about n octets of the header.

I would prefer something like:
  This information element carries a series of octets from the start of
  of the IP header of a sampled packet.  The size of the packet section
  is controlled by the PSAMP device and MAY continue into the payload.

  The element MUST NOT contain any padding and if the PSAMP device is
  configured to stop after n octets, at the end of the IP header or
  after m octets of payload, the size of the field must be adjusted
  to match the number of bytes exported using either a variable length
  field or a template containing a field of the correct size.

regards

Andrew

---

From: Thomas Dietz <[email-masked]>
Date: Mon, 27 Mar 2006 13:37:22 +0200

Andrew, Paul,

I agree to Andrews comments and I like his wording very much. I think this 
makes the IE really clear. I guess we will get something like an 
Implementation Guide as more and more people will implement PSAMP.

Regards,

Thomas

-- 
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany