epb: add three new epb options, packetid, queue and verdict #91

chaudron · 2020-04-09T08:32:21Z

Signed-off-by: Eelco Chaudron echaudro@redhat.com

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

chaudron · 2020-04-09T08:35:13Z

Not sure if I had to add my name as an editor if I added text. If not I can remove it, no problem.

Also for some reason, I'm not getting emails from the pcap-ng-format mailing list. I've asked the pcap-ng-format-owner to verify I'm properly registered but got no update. So I will monitor the list manually, but if you do send related emails there I would appreciate it if you can put me on CC directly.

packetfoo · 2020-04-09T08:45:50Z

draft-tuexen-opsawg-pcapng.xml

+
+            <t>Example: '0'.</t>
+
+            <t hangText="epb_verdict:"><vspace blankLines="0"/>The epb_verdict


What does "verdict" mean? I assume it means firewall/ACL activity like "drop", "reject", "accept"? Not all readers might be familiar with the term, so it would be good to explain it just a bit :-)

Added some additional explanation

By the way, the Linux_eBPF_TC and Linux_eBPF_XDP verdict types appear to be integral values; if so, are they in the byte order of the host writing the file (so that a little-endian machine will write them as little-endian numbers and a big-endian machine will write them as big-endian numbers)?

And is the hardware verdict type an opaque blob of bytes?

(The byte order question also applies to the packet ID and queue options, with presumably the same answer.)

The Linux_eBPF_TC and Linux_eBPF_XDP are stored a uint64 and hence the same as all other metadata in the block, so in host order as explained in the "Endianness" section.

You are right about the hardware verdict type, this is an opaque blob of bytes.

Packet and queue ID are the same as any other option, for example, epb_dropcount, which are stored as explained in the "Endianness" section.

mcr · 2020-04-09T14:20:44Z

Eelco Chaudron <notifications@github.com> wrote: Not sure if I had to add my name as an editor if I added text. If not I can remove it, no problem. Generally, in an IETF document, we would acknowledge all contributors in the Acknolwedgements section, but only list the lead authors/editors in the heading. There is a guideline for five authors only on an RFC, and we'll justify or prune names if/when we get closer to that stage.

…

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

draft-tuexen-opsawg-pcapng.xml

netoptimizer · 2020-04-14T12:58:59Z

General question what does "epb" stand for?

packetfoo · 2020-04-14T13:13:05Z

General question what does "epb" stand for?

It stands for "Enhanced Packet Block", which is the most commonly used block type to store each packet.

netoptimizer · 2020-04-14T13:44:50Z

General question what does "epb" stand for?

It stands for "Enhanced Packet Block", which is the most commonly used block type to store each packet.

Thanks for explaining that! :-)

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

chaudron · 2020-04-15T07:38:35Z

Generally, in an IETF document, we would acknowledge all contributors in the Acknolwedgements section, but only list the lead authors/editors in the heading. There is a guideline for five authors only on an RFC, and we'll justify or prune names if/when we get closer to that stage.
…

Ok, will leave it in for now, or let me know and I'll remove/move my name.

chaudron · 2020-04-22T15:49:35Z

Anything pending from my side, or something I can do to get this merged?

guyharris · 2020-04-22T17:50:20Z

draft-tuexen-opsawg-pcapng.xml

+            type, while the following octets contain the actual verdict data,
+            whose size depends on the verdict type, and hence from the value
+            in the first octet. The verdict type can be: Hardware (type
+            octet = 0, size = XXX), Linux_eBPF_TC (type octet = 1, size = 8


"XXX" presumably meaning "variable".

Yes, it means variable, copied this layout from the epb_hash option above. I will change XXX to variable, as it makes more sense.

Yes, the epb_hash option is vague about those hashes in a fashion that doesn't make it clear whether 1) they haven't yet decided how big the hash should be or 2) deliberately left it unspecified to allow different-width hashes to be used.

guyharris · 2020-04-22T17:51:27Z

draft-tuexen-opsawg-pcapng.xml

+            type, while the following octets contain the actual verdict data,
+            whose size depends on the verdict type, and hence from the value
+            in the first octet. The verdict type can be: Hardware (type
+            octet = 0, size = XXX), Linux_eBPF_TC (type octet = 1, size = 8


These should probably point to a source indicating what the values for Linux eBPF TC and Linux eBPF XDP values signify.

What about:

The verdict type can be: Hardware (type
octet = 0, size = variable), Linux_eBPF_TC (type octet = 1, size = 8
(64-bit unsigned integer), value = TC_ACT_* as defined in the Linux
pck_cls.h
include), Linux_eBPF_XDP (type octet = 2, size = 8 (64-bit unsigned
integer), value = xdp_action as defined in the Linux
pbf.h
include).

So where can these "pck_cls.h" and "pbf.h" files be found? They can't be found in any obvious place in the Linux 5.6.7 kernel source, at least not if the source tarball is downloaded and unpacked and a "find" command is run in the top-level directory.

Nice... The Github editor removed the ref links I put in...

The verdict type can be: Hardware (type octet = 0, size = variable), Linux_eBPF_TC (type octet = 1, size = 8 (64-bit unsigned integer), value = TC_ACT_* as defined in the Linux <eref target="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/pkt_cls.h">pck_cls.h</eref> include), Linux_eBPF_XDP (type octet = 2, size = 8 (64-bit unsigned integer), value = xdp_action as defined in the Linux <eref target="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/bpf.h">pbf.h</eref> include).</t>

guyharris · 2020-04-22T17:56:03Z

draft-tuexen-opsawg-pcapng.xml

+            example could be where an XDP program on ingress captures a packet,
+            which gets modified and then exits the XDP program. In this case,
+            two packets are in the capture file, which are not identical but
+            the epb_packetid can be used correlate them.</t>


So the capture has two packets that are different from each other but that are the same?

This probably needs to be rephrased in a way to make it clearer that "the packet" doesn't refer to the exact sequence of octets. Perhaps it should include a less-exotic example than an XDP one, such as a packet captured on a multiple-interface router that arrives on one interface, gets its IP TTL reduced, and is transmitted on another interface.

Like the idea, what about changing the example to:

An example could be a router that captures packets on all its interfaces in both directions. When a packet hits interface A on ingress, an ECB entry gets created, TTL gets decremented, and right before it egresses on interface B another ECB entry gets created in the trace file. In this case, two packets are in the capture file, which are not identical but the epb_packetid can be used to correlate them.

What's an "ECB"?

Ooops, should be EPB :(

chaudron · 2020-04-30T16:07:58Z

Commited the changes suggested by @guyharris as I got no further feedback. Please let me know if I need to change more...

guyharris · 2020-04-30T16:35:52Z

draft-tuexen-opsawg-pcapng.xml

+            epb_packetid option is a 64-bit unsigned integer that uniquely
+            identifies the packet. If the same packet is seen by multiple
+            interfaces and there is a way for the capture application to
+            correlated them, the same epb_packetid value must be used. An


That should be "to correlate them".

Thanks will fix in next update...

guyharris · 2020-04-30T16:37:21Z

draft-tuexen-opsawg-pcapng.xml

+            <t hangText="epb_verdict:"><vspace blankLines="0"/>The epb_verdict
+            option stores a verdict of the packet. The verdict indicates what
+            would be done with the packet after processing it. For example, a
+            firewall implemented with eBPF could drop the packet. This verdict


I'd just say "a firewall could drop the packet"; how the firewall rules are internally implemented is a detail.

Will remove it!

See the following pull request for details: IETF-OPSAWG-WG/draft-ietf-opsawg-pcap#91 Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

chaudron · 2020-05-04T09:09:02Z

@guyharris pushed the suggested changes and fixed one other issue with a duplicate ecb_option number. Anything else?

chaudron · 2020-05-12T13:10:49Z

@guyharris anything else I can do to speed up the acceptance of this change? I've done a rough implementation in WireShark to display these new fields.

chaudron · 2020-06-02T19:35:03Z

@guyharris @mcr anything I can do to speed up this merge request? Asking as I have a project that would really benefit from this.

guyharris · 2020-06-02T19:52:38Z

@guyharris @mcr anything I can do to speed up this merge request? Asking as I have a project that would really benefit from this.

I'm OK with it; @mcr, are you OK with @chaudron's appearance in the authors list?

chaudron · 2020-06-03T15:05:44Z

Thanks a lot for merging this!!

epb: add three new epb options, packetid, queue and verdict

1d89b75

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

packetfoo reviewed Apr 9, 2020

View reviewed changes

netoptimizer reviewed Apr 14, 2020

View reviewed changes

draft-tuexen-opsawg-pcapng.xml Outdated Show resolved Hide resolved

netoptimizer reviewed Apr 14, 2020

View reviewed changes

draft-tuexen-opsawg-pcapng.xml Outdated Show resolved Hide resolved

epb: fixed some spelling errors and add verdict clarification

294fa5f

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

guyharris reviewed Apr 22, 2020

View reviewed changes

guyharris reviewed Apr 30, 2020

View reviewed changes

chaudron added 2 commits May 1, 2020 10:01

epb: changes based on comments from guyharris

43fa650

epb: fix assigned ID to epb_queue

b5b2c08

mcr merged commit 587eb9f into IETF-OPSAWG-WG:master Jun 3, 2020

chaudron deleted the ecb_options branch June 3, 2020 15:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

epb: add three new epb options, packetid, queue and verdict #91

epb: add three new epb options, packetid, queue and verdict #91

chaudron commented Apr 9, 2020

chaudron commented Apr 9, 2020

packetfoo Apr 9, 2020

chaudron Apr 15, 2020

guyharris Apr 29, 2021

guyharris Apr 29, 2021

chaudron Apr 29, 2021

mcr commented Apr 9, 2020 via email

netoptimizer commented Apr 14, 2020

packetfoo commented Apr 14, 2020

netoptimizer commented Apr 14, 2020

chaudron commented Apr 15, 2020

chaudron commented Apr 22, 2020

guyharris Apr 22, 2020

chaudron Apr 23, 2020 •

edited

guyharris Apr 23, 2020

guyharris Apr 22, 2020

chaudron Apr 23, 2020

guyharris Apr 23, 2020

chaudron Apr 24, 2020

guyharris Apr 22, 2020

chaudron Apr 23, 2020

guyharris Apr 23, 2020

chaudron Apr 24, 2020

chaudron commented Apr 30, 2020

guyharris Apr 30, 2020

chaudron May 1, 2020

guyharris Apr 30, 2020

chaudron May 1, 2020

chaudron commented May 4, 2020

chaudron commented May 12, 2020

chaudron commented Jun 2, 2020

guyharris commented Jun 2, 2020

chaudron commented Jun 3, 2020


		<t>Example: '0'.</t>

		<t hangText="epb_verdict:"><vspace blankLines="0"/>The epb_verdict

epb: add three new epb options, packetid, queue and verdict #91

epb: add three new epb options, packetid, queue and verdict #91

Conversation

chaudron commented Apr 9, 2020

chaudron commented Apr 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcr commented Apr 9, 2020 via email

netoptimizer commented Apr 14, 2020

packetfoo commented Apr 14, 2020

netoptimizer commented Apr 14, 2020

chaudron commented Apr 15, 2020

chaudron commented Apr 22, 2020

Choose a reason for hiding this comment

chaudron Apr 23, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chaudron commented Apr 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chaudron commented May 4, 2020

chaudron commented May 12, 2020

chaudron commented Jun 2, 2020

guyharris commented Jun 2, 2020

chaudron commented Jun 3, 2020

chaudron Apr 23, 2020 •

edited