On 22/01/20 17:04, Christian Hopps wrote:
On Jan 22, 2020, at 11:21 AM, João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> wrote:
On 22/01/20 01:11, Christian Hopps wrote:
João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> writes:
On 21/01/20 16:06, João Valverde wrote:
On 21/01/20 16:01, Jeff Morriss wrote:
We've been having fun with multiple PDUs in a single IP frame with
SCTP for years. While there's room for improvement it's worked
pretty well.
Maybe I didn't explain well, but that's completely different to
multiple IP packets encapsulated in a single frame. L4 multiplexing is
nothing new, I agree.
How would this protocol stack even look in the packet list? Surely it
can only display the outer IP header with ESP/IPTFS protocol? We already
have some issues to iron out with the much simpler case of IP over GRE
(bug 3791 for example).
One idea, and it's just that, I haven't studied the issue in depth,
would be using an IPTFS Cooked Capture DLT type.
I'm not versed well enough in wireshark yet to know what a "cooked capture DLT type" is, but I can show what I have now. :)
I still haven't stamped anything with "comes from" or "depends on", and I'd also like to have datablock summary lines include the actual size of that datablock data...
Basically I decode as:
- IPTFS
- Header fields
- Array of datablocks
- Subtree of contained packets:
- Array of Dissected IP packets
- 1st packet is the completion of a fragmented packet if that happened.
You'll notice the final datablock doesn't have a packet (7 data blocks 6 packets), the first packet is the reconstructed packet from the first datablock which is the last of the fragments. The last datablock is the start of a new fragmented packet so that will appear later (the inner packet sizes are from an imix stream of 40, 576 and 1500 FWIW)
[snip]
That's pretty good, nice work.
What does tshark without the -V flag show? My guess is that all that compresses to:
8 13.13.13.11 13.13.13.2 IPTFS <Frame len> <some colinfo like SPI=1113 Blocks=7>
You guess correctly. :)
It would be nice to see each encapsulated IP flow (after reassembly if necessary) in this list. Both from a usability stand point and also because it enables a lot of other stuff, like better filtering, follow stream, etc.
A cooked capture, in particular a Linux cooked capture, is a link-layer pseudo-header for the "any" interface. It doesn't correspond to any real protocol like ETH or PPP. The same concept could possibly be applied here to display each inner IP packet in the packet list. For IPTFS a frame "interface" could be the IPTFS ESP SPI. Usually dumpcap/libpcap provides the DLT type. Major caveat, I don't know how difficult it would be to inject new cooked frames from libwireshark itself.
That sounds really good.
Security Associations (SAs which the SPI identifies) are actually uni-directional (although they almost *always* come in pairs inbound, outbound), so we probably would want the psuedo-header to be based on the tuple: (ip-src, ip-dst, spi), as one might have 2 unique SAs with the same SPI.
FWIW, I think the same psuedo-header should probably be used by non-IPTFS IPsec code too (it also dissects the single inner packet it carries -- when operating in tunnel mode -- when in transport mode it will be dissecting L4 data, but this just means the conceptual inner IP header is the same as the outer, so same ip-src, ip-dst tuple applies).
IPsec in tunnel mode is not so different from OpenVPN or even GRE from a
conceptual point of view. That's a pretty major redesign that requires
careful consideration and because the encapsulation is one-to-one and
not one-to-many like IPTFS it doesn't have most of the limitations that
IPTFS would have. Things work well most of the time in that case so
finding momentum to implement a link-layer encapsulation pseudo-header
so broadly might be difficult.
Thanks,
Chris.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
