Subject: psamp-info: transport/udp/tcpPayloadPacketSection

From: Gerhard Muenz <[email-masked]>
Date: Wed, 01 Feb 2006 09:54:25 +0100

Dear all,

In the psamp-info draft, there is an IE for IP payload, L2 payload and 
MPLS payload.
Are there any reasons for not having a similar IE for transport layer 
payload, e.g. udp|tcpPayloadPacketSection or a generic 
transportPayloadPacketSection?

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: Andrew Johnson <[email-masked]>
Date: Wed, 01 Feb 2006 13:45:30 +0000

> transportPayloadPacketSection?

A generic transport payload IE is not feasible because to implement
properly an implementation would have to understand and parse all
transport protocols, including ones which are yet to be defined.

At this time, it is expected that the IP payload type will be sufficient
because correct interpretation of the transport payload will most likely
require much of the information from the transport header, and the IP
payload IE will provide both.

If you, or anyone, has an application that would require that PSAMP be
extended in some way then please mail the list details of the application
and we can discuss the best way to address the requirements, possibly
requesting new IEs as needed.  Don't forget, however, that new IEs can
be requested at any time in the future, so we don't have to cover all
cases right now.

regards

Andrew

--
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: Gerhard Muenz <[email-masked]>
Date: Thu, 02 Feb 2006 09:22:47 +0100

Dear Andrew, all,

Comments inline:

> transport protocols, including ones which are yet to be defined.

I thought of a generic transportPayloadPacketSection similar to the 
sourceTransportPort that exists besides udp|tcpTransportPort. In any 
case, a monitor would only export the information it is able to retrieve 
from a packet.

Apart from the generic type, is there any argument against IEs for 
udp|tcpPacketPayloadSection? Since IEs for almost all UDP/TCP header 
fields exist, the payload type would cover the remaining unparsed packet 
data.

> payload IE will provide both.

The IP payload type is sufficient but inefficient if you are not 
interested in the whole transport header but only in some specific 
fields (such as port numbers). In this case you would export much more 
data than you need.

> be requested at any time in the future, so we don't have to cover all

An application I'm working on is signature detection on sampled packets.

Regards,
Gerhard

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 02 Feb 2006 17:31:14 +0000

Hi Gerhard

If I recall correctly, the packet section fields were defined to
meet the PSAMP requirements and provide a minimum requirement for
the basic packet reports.  The extended packet reports can contain
any information you like as long as you have an IE for it, so I hope
you don't feel that the current PSAMP drafts will restrict what you
want to do.

Some more inline:

> case, a monitor would only export the information it is able to retrieve 

Sure, but the sourceTransportPort is restricted to specifically TCP,
UDP and SCTP.  Where is gets a bit woolly, and the part I don't like, is
the option to use it for future protocols, which could lead to different
implementations of the protocol doing different things for the same
traffic.  I think that all our IEs should have very solid definitions.

> fields exist, the payload type would cover the remaining unparsed packet 

If a new IE was created to cover UDP, TCP and SCTP payloads then I suppose
that would be fine.  The option to use it with future types is debatable
but I wouldn't object if it was consistent with the transportSourcePort
field.

[SNIP]
> An application I'm working on is signature detection on sampled packets.

OK, to summarise then.  Would I be right in saying that current PSAMP drafts
meet your requirements with the basic packet reports, and could be met more
efficiently with certain extended packet reports?  To be more efficient
still you want a new IE for just the TCP or UDP (and maybe SCTP) payload?

In which case I would say that this new IE doesn't specifically belong in
the PSAMP drafts, it is merely one of the many IEs that can be used in an
extended packet report.  That said, the IE may be relevant and generally
useful enough to be included in the PSAMP drafts as a good candidate for
extended packet reports.  The alternative is for you to request the IE
yourself on the IPFIX mailing list.

Cheers

Andrew

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 02 Feb 2006 19:26:24 +0100

Hi Andrew,

Of course, the psamp-info draft does not restrict me since I can always 
define my own IEs. It's just that having such an IE in the standard 
would have looked natural to me.

Cheers,
Gerhard

Andrew Johnson wrote:
>> case, a monitor would only export the information it is able to 
>> retrieve from a packet.
> 
> 
>> fields exist, the payload type would cover the remaining unparsed 
>> packet data.
> 
>