[pcap-ng-format] Proposing new block type for PCAP-NG (UNCLASSIFIED)

[Guy Harris]

On Mar 26, 2015, at 9:57 AM, "Renard, Kenneth D CIV USARMY ARL (US)" <kenneth.d.renard.civ at mail.mil> wrote:

> 1.  In the Section Header Block, I propose a new option 'shb_host'.  This would
> be very similar to the existing shb_* fields, but specify the name of the host
> that executed the data collection
> 
>    Name:         shb_host
>    Code:         5?
>    Length:       Variable
>    Description:  An UTF-8 string containing the name of the host
>                  used to create this section.
>    Example:      "foo.bar.com", "Sensor XYZ", "Router X, Span port 4"

"Router X, Span port 4" sounds more like a comment for an Interface Description Block than a description of the host on which the data was collected.  If the capture is being done on the router *itself* - i.e., with code running on the router, rather than with code running on a machine plugged into a span port on the router" - it'd probably be "Router X", with the interface description in the IDB being "Span port 4".  Otherwise, it'd be some name for the host plugged into the router port.

The other examples seem OK.

The block type makes sense to me; I don't see any issues with it.

> 2.  A proposed new block type:  "Location Information Block".  The purpose
> is to provide some idea of where the capture is taking place.  This could
> be a descriptive location such as "DMZ", "Server Room", or "Starbucks".  For
> our purposes, it would be a geographic location specified in some format.
> Specific formats could be: "Lattitude-Longitude-Altitude", "Orientation"
> (pitch, yaw, roll), or "XYZ" (meters).  This will be helpful in correlating
> performance of wireless networks given some location and thus range
> information.  I propose some specifics here, which I would appreciate some
> feedback on.  I would like this to be useful beyond just our community.
> 
>    Block Name:         Location Information Block
>    Block Type:         (4 bytes)
>    Block Total Length: (4 bytes)
>    InterfaceID:        (4 Bytes)
>    Timestamp (High):   (4 Bytes)
>    Timestamp (Low)     (4 Bytes)
>    Options:            Variable
> 
> Multiple Location Information Blocks would be allowed,

Good - laptops/tablets/smartphones *are* known as "mobile" devices for a reason. :-)

> so there is a need
> to put a timestamp on each position record, and we should tie this to a
> specific interface mostly so that we can use its timestamp precision.
> This would also allow you to have multiple interfaces at different
> locations.

Sounds good.  Presumably if there's no LIB for a particular interface, the location of that interface would be unknown.

Presumably if you have a mobile machine with multiple interfaces (two Wi-Fi, or Wi-Fi + mobile phone modem, for example), multiple LIBs will be produced when the machine moves sufficiently to deserve that.

If somebody's capturing while in motion, and we're not interested in position or orientation information when packets aren't arriving, we could have those options available for both LIBs and packet blocks, and say that the position/orientation information for a packet is unchanged from whatever the last values were for that interface if the options aren't present.  That might allow less stuff to be written if we're only interested in the position and orientation at the time packets are captured.

>    Option 3:  Orientation (12 bytes):
> 				
>        Bytes 0-3:  32-bit signed integer
>                    Pitch angle expressed in 10^-6
>                    degrees.  Example: 
>                    45000000 = 45.000000 degrees
>        Bytes 4-7:  32-bit signed integer
>                    Roll angle expressed in 10^-6
>                    degrees.  Example: 
>                    115000000 = 115.00 degrees
>        Bytes 8-11: 32-bit signed integer
>                    Yaw angle expressed in 10^-6
>                    degrees.  Example: 
>                    -500000 = -0.50 degrees

That's not really *location* information; we might want to rename the block to Location/Orientation Information Block or something such as that.

>    Option 4:  X-Y-Z (12 bytes):
> 
>        Bytes 0-3:  32-bit signed integer
>                    X-axis distance meters from origin
>        Bytes 4-7:  32-bit signed integer
>                    Y-axis distance meters from origin
>        Bytes 8-11: 32-bit signed integer
>                    Z-axis distance meters from origin

Is there a standard origin (say, the North Pole) from which those are measured, is the origin provided out of band to the program interpreting the capture, or should there be a block that supplies the origin?

This also may not work well for space travel outside Earth orbit - it's about 54 billion meters from Earth to Mars:

	http://www.space.com/14729-spacekids-distance-earth-mars.html

If that becomes an issue, we could add a new option with 64-bit offsets.

I presume less-than-meter resolution isn't required; if that becomes an issue, the 64-bit-offset could be in less-than-meter units.

>    Option 5:  Description (Variable)
>               UTF-8 string containing some textual description of
>               location.  (e.g. "DMZ", "Server Room", or "Starbucks")

Presumably we could, for example, have most LIBs, and those packet blocks that need to update location information if we go that way, not provide that option, and only provide that option if the textual description needs to be updated, so you don't, for example, repeatedly say "Starbucks" while you're walking around the coffee shop.