Re: New official link-layer type request

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

Hi again

I think maybe this will explain things a bit better. Li systems correlate
everything using LI_ID and for them this serves a purpose of being
their equivalent of a Link Layer Type. From what I sent earlier, the 
tshark CC
example output, you can see that one of ELEE protocol's fields is
"Lawful Interception Identifier". So, every network packet needs this LI_ID
in its encapsulation header. When it's done this way, LEAs can filter out
traffic based on their target IDs (LI_ID). This is very useful for VoIP 
for example
when they want to listen to a target's conversation. Then if ELEE 
encapsulation
is used, they can do a search based on LI_ID and use RTP player in wireshark
to listen to the conversation. ELEE CC PDU encapsulates Ethernet frames and
hands off that part of data to Ethernet dissector.



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