Re: New official link-layer type request

[Damir Franusic <damir.franusic () gmail com>]

Hi Michael

You know, I also share your disdain for ASN.1 format but in the mobile 
networks
for example, it is used to define most protocols (TCAP, GSM MAP, etc.) 
and I don't
see that changing any time soon.

I think you may have misunderstood me. I only mentioned SCTP in context 
of explaining
how the systems works and traffic is not analyzed while in SCTP DATA 
block, that is
only our internal communication. Data format of SCTP DATA with PPID 65 
is this ELEE
format I am talking about.



The traffic we carry over SCTP is ELEE encapsulated but the end result 
is either
PCAP, ASN.1 encoded using BER or ELEE. Also, It is not only "captures" 
or network
packet data that is carried, but also LI specific context data which is
unrelated to network headers or link layer types; they use some custom 
events
describing target state changes and whatever.


Regarding why the existing DLT doesn't work for me is because this DLT 
is number
147 and from what I've read:

"Values in the range 147 through 162 are reserved for private use; if 
you have some
link-layer header type that you want to use within yourorganization, 
with the capture
files using that link-layer header type not ever besent outside your 
organization"


I would like this protocol dissector to be included in some future 
version of wireshark
and then I would not be able to use this DLT since it would become 
public. The idea is
to make a solution for LEAa that is compatible with our Lawful 
Interception Software and
is not something custom or patched but a program which can be downloaded 
by anyone. By
doing so we would maybe be able to avoid that ASN.1 BER nightmare.


On 5/11/19 10:18 PM, Michael Richardson wrote:
> Hi, it would be great if you just typed, rather than **TYPE** all over the
> place.  Maybe you are writing in HTML, in which case realize that you shouldn't.
>
> Damir Franusic <damir.franusic () gmail com> wrote:
>      > they describe everything in great detail by using *ASN.1*notation which is
>      > then encoded using
>      > *BER *when sent by wire.
>
> Wow, talk about driving the price of LEA software up 1000x by invoking 30yr
> old ASN.1 for no good reason.  At least they could have used JSON or CBOR.
>
>      > I have already created a dissector for *Wireshark* to be able to debug and
>      > analyze our internal SCTP traffic
>      > and inspect aggregated network data for which I use Wireshark's
>      > *WTAP_ENCAP_USER0 *Like Layer Type.
>      > Unfortunately, I don't have the documentation/specification for *ELEE/PCAP*
>      > ready just yet, but that would come
>      > later on. I would like to get an official *DLT*for our product
>      > (*LINKTYPE_ELEE*), just like we got *
>      > *
>      > *SCTP PPID from IANA*. The protocol and the dissector would be used mainly by
>      > *LEAs*and I don't think it would
>      > cause any harm to *tcpdump* and/or *Wireshark* community to get closer to
>      > being able to provide Lawful Interception
>      > features. The plan is to include the dissector in the official *Wireshark*
>      > version when it's finished.
>
> I don't really understand how your traffic is different.
> I understand you carry your captures over SCTP, but once it has been received
> and placed on disk, it sounds likt it is either a PCAP/PCAPNG file, or it's
> this ELEE format (which we have nothing to do with).
>
> Maybe you are thinking you should be able to analyze traffic that is inside
> the SCTP stream without storing it?  Or maybe I just don't understand your request.
>
>      > I have also attached a PDF slideshow of our product which you may or may not
>      > find interesting. The interesting
>      > part is: We will be the first to offer *LI* systems on *ARM* based *SBCs
>      > (*Single Board Computers).
>
>      > *Example tshark output for IRI:*
>
>      > Frame 1: 161 bytes on wire (1288 bits), 161 bytes captured (1288 bits)
>      >     Encapsulation type: USER 0 (45)
>      >     Arrival Time: May 10, 2019 20:21:59.2065333272 CEST
>      >     [Expert Info (Note/Sequence): Arrival Time: Fractional second 2065333272
>      > is invalid, the valid range is 0-1000000000]
>      >         [Arrival Time: Fractional second 2065333272 is invalid, the valid
>      > range is 0-1000000000]
>      >         [Severity level: Note]
>      >         [Group: Sequence]
>      >     [Time shift for this packet: 0.000000000 seconds]
>      >     Epoch Time: 1557512519.2065333272 seconds
>      >     [Time delta from previous captured frame: 0.000000000 seconds]
>      >     [Time delta from previous displayed frame: 0.000000000 seconds]
>      >     [Time since reference or first frame: 0.000000000 seconds]
>      >     Frame Number: 1
>      >     Frame Length: 161 bytes (1288 bits)
>      >     Capture Length: 161 bytes (1288 bits)
>      >     [Frame is marked: False]
>      >     [Frame is ignored: False]
>      >     [Protocols in frame: elee]
>
> That's nice, but can you tell us why an existing DLT won't work for you?
>
> --
> ]               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    [
--
Damir Franusic

email: damir.franusic () gmail com
http://ele2.io/

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers