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