[tcpdump-workers] New official link-layer type request
Hi My name is Damir and I am a founder of a Croatian based company called *Socket d.o.o. * We are currently working on an *ETSI compliant Lawful Interception*solution; It is a work in progress but we already have couple of clients in need of this solution. The problem with *LI*is that governments impose the law on the *ISPs*and other Communication Provides (*CSPs*), making them obliged to purchase the *LI * software or implement it themselves. These system are standardized to some degree by the European Telecommunications Standards Institute (*ETSI*), but that is just the first part of the story. *L**I* systems are quite complex but from the perspective of *LEAs*(Law Enforcement Agencies), they consist of *2 parts; Backend*and *Frontend*. *Backend*is actually what is normally called a *GUI*or a *Web Interface*, so the reversal of terminology can be a bit confusing at times. *ELEE*software is a data interception (*Fronted*) system that passively tracks *IP traffic* and delivers the data of interest to *LEAs*. The format of that delivery if defined by *ETSI*; they describe everything in great detail by using *ASN.1*notation which is then encoded using *BER *when sent by wire. *Why do we need a new DLT? *We would like to offer *ELEE*solution to our customers (*ISPs* and/or *CSPs)*, but *LEAs*are also a vital part of this *2-part business*. *LEAs* are quite prone to having lots of issues with data analysis (*Backend part*) software, which is quite odd since they also follow *ETSI* governed standards. Some even demand a regular *PCAP*format for data delivery due to complete lack of *Backend* software. *LI *data delivery comprises both *packet data* and intercept *metadata* which is completely *unrelated to network stack. *Thisis also one of the reasons to ask for a *new DLT.* *ELEE *solution supports *PCAP*, *BER*and *ELEE/PCAP.*We created our own protocol which is transferred using *SCTP*and is registered with *IANA**with SCTP PPID 65*. We would like to offer a way to analyze *ELEE/PCAP * format with *Wireshark*and bring *LI*capabilities to a well established network analysis software. That would also be very interesting to *LEAs*; they would be able to use *Wireshark *as their official * * *Backend* data analysis tool. They use different terminology and fields to inspect data, and that is what *ELEE/PCAP *is all about; *bridging**the gap between **LI**and **PCAP**. * 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. Sorry for the long summary, I just wanted to give you a little intro and not cause any headaches or tech rage. 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). Company info: *https://sudreg.pravosudje.hr/registar/f?p=150:28:0::NO:28:P28_SBT_MBS:080973259* Website(temp until the project is finished): *http://socket.hr* IANA SCTP PPID 65: *https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25* P.S. You can find some tshark output for the *ELEE/PCAP* protocol dissector (both IRI and CC, the only two main PDU types) *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-10] [Arrival Time: Fractional second 2065333272 is invalid, the valid range is 0-10] [Severity level: Note] [Group: Sequence] [Time shift for this packet: 0.0 seconds] Epoch Time: 1557512519.2065333272 seconds [Time delta from previous captured frame: 0.0 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 0.0 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] ELEE Protocol Protocol version: 1 PDU type: Target PDU (1) Source node: ele
Re: [tcpdump-workers] New official link-layer type request
Hi Like I sad, I don't have the complete documentation ready, but this is the general format: +-+ | Version | | (1 Octet) | | | +-+ | PDU Type | | (1 Octet) | | | +-+ | Source ELLE Node | | NULL terminated ASCII string | | (1 Octet min for \0) | | | +-+ | Destination ELEE Node | | NULL terminated ASCII string | | (1 Octet min for \0) | | | +-+ | ELEE PDU Payload | . (Remaining octets) . . . . . PDU Payload part is the rest of the packet data and will be interpreted based on PDU Type. On 5/11/19 10:09 PM, Guy Harris wrote: On May 11, 2019, at 7:26 AM, Damir Franusic wrote: *Example tshark output for IRI:* ... ELEE Protocol Protocol version: 1 PDU type: Target PDU (1) Source node: elee.ppd.node_1 Destination node: . Target PDU Lawful interception identifier: dhcp_li_id Target PDU data type: Intercept Related Information (IRI) (1) Sequence number: 0 Timestamp: May 10, 2019 18:21:59.723619839 UTC IRI configuration Active: True Delivery format: ELEE (3) Handover connection: Handover directory: Aggregation factor: 2 Delivery timeout: 0 Communication identifier Operator identifier: Network element identifier: Communication identifier number (CIN): 0 Data part size: 95 IP IRI IRI type: IRI-REPORT (4) Access event type: accessAttempt (0) Target username: 001cbf0dbfd7 Internet access type: Unknown (0) IP version: IPv4 protocol (1) Target IPv4: 0.0.0.0 Target network id: 00:1c:bf:0d:bf:d7 POP port number: 0 Target call-back number: POP IP address: Authentication type: AAA provided by DHCP (3) ... *Example tshark output for CC:* ... *ELEE Protocol* Protocol version: 1 PDU type: Target PDU (1) Source node: elee.ppd.node_1 Destination node: . Target PDU Lawful interception identifier: test_li_id Target PDU data type: Content of Communication (CC) (2) Sequence number: 0 Timestamp: May 10, 2019 18:27:56.677651565 UTC CC configuration Active: True Delivery format: ELEE (3) Handover connection: Handover directory: Aggregation factor: 10 Delivery timeout: 0 Communication identifier Operator identifier: Network element identifier: Communication identifier number (CIN): 0 Data part size: 60 So what would the exact format of the header be for this link-layer type? -- Damir Franusic email: damir.franu...@gmail.com http://ele2.io/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New official link-layer type request
On May 11, 2019, at 2:51 PM, Damir Franusic wrote: > PDU types are extendable and there might be more of them in the future. I > wanted to make it like this so adding new types would not present a big > issue. I can define the two PDU types used at present moment but maybe it > would be more practical to leave PDU payload part as generic octet stream if > that's possible. Why would it be more practical not to define *what you already implementString s are pure ASCII C null terminated, no need for utf-8. > The formats of PDUs will be described in protocol documentation, sure. I am > just not sure how many types of PDUs will it consist of when it's done. Is we > just leave as a data octet stream, any kind of PDU added later would not > break the initial design. If you're planning on extending this, then what you should do is: put a specification for the *current* set of PDU types on your Web site, *including* the payload formats for each of those PDU types; update it as *new* PDU types are added; and the entry for your LINKTYPE_ value on tcpdump.org can link to that specification. pcapng has a specification: http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-tuexen-opsawg-pcapng.xml&modeAsFormat=html/ascii&type=ascii and it *does* list the block type values, and formats, for existing block types, and the option number values, and formats, for existing options, but that does *not* prevent it from being extensible; as new block types or options are added, the specification is updated. Our goal is to have a registry of link-layer header types that would allow somebody to write their *own* code to process pcap or pcapng files with packets of that type *without* having to read tcpdump or Wireshark code to figure out how to analyze it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New official link-layer type request
On May 11, 2019, at 1:39 PM, Damir Franusic wrote: > Like I sad, I don't have the complete documentation ready, When you have the complete documentation ready, let us know. > but this is the general format: > > +-+ > | Version | > | (1 Octet) | > | | > +-+ > | PDU Type | > | (1 Octet) | > | | What are the PDU type values? > +-+ > | Source ELLE Node | > | NULL terminated ASCII string | > | (1 Octet min for \0) | So that's pure ASCII, without, for example, any letters with diacritical marks, so it doesn't need full UTF-8? > | | > +-+ > | Destination ELEE Node | > | NULL terminated ASCII string | > | (1 Octet min for \0) | And the same applies there? > | | > +-+ > | ELEE PDU Payload | > . (Remaining octets) . > . . > . . > > PDU Payload part is the rest of the packet data > and will be interpreted based on PDU Type. Presumably the formats of the PDU payloads will be described in the complete documentation. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New official link-layer type request
On May 11, 2019, at 7:26 AM, Damir Franusic wrote: > *Example tshark output for IRI:* ... > ELEE Protocol >Protocol version: 1 >PDU type: Target PDU (1) >Source node: elee.ppd.node_1 >Destination node: . >Target PDU >Lawful interception identifier: dhcp_li_id >Target PDU data type: Intercept Related Information (IRI) (1) >Sequence number: 0 >Timestamp: May 10, 2019 18:21:59.723619839 UTC >IRI configuration >Active: True >Delivery format: ELEE (3) >Handover connection: >Handover directory: >Aggregation factor: 2 >Delivery timeout: 0 >Communication identifier >Operator identifier: >Network element identifier: >Communication identifier number (CIN): 0 >Data part size: 95 >IP IRI >IRI type: IRI-REPORT (4) >Access event type: accessAttempt (0) >Target username: 001cbf0dbfd7 >Internet access type: Unknown (0) >IP version: IPv4 protocol (1) >Target IPv4: 0.0.0.0 >Target network id: 00:1c:bf:0d:bf:d7 >POP port number: 0 >Target call-back number: >POP IP address: >Authentication type: AAA provided by DHCP (3) ... > *Example tshark output for CC:* ... > *ELEE Protocol* >Protocol version: 1 >PDU type: Target PDU (1) >Source node: elee.ppd.node_1 >Destination node: . >Target PDU >Lawful interception identifier: test_li_id >Target PDU data type: Content of Communication (CC) (2) >Sequence number: 0 >Timestamp: May 10, 2019 18:27:56.677651565 UTC >CC configuration >Active: True >Delivery format: ELEE (3) >Handover connection: >Handover directory: >Aggregation factor: 10 >Delivery timeout: 0 >Communication identifier >Operator identifier: >Network element identifier: >Communication identifier number (CIN): 0 >Data part size: 60 So what would the exact format of the header be for this link-layer type? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New official link-layer type request
PDU types are extendable and there might be more of them in the future. I wanted to make it like this so adding new types would not present a big issue. I can define the two PDU types used at present moment but maybe it would be more practical to leave PDU payload part as generic octet stream if that's possible. String s are pure ASCII C null terminated, no need for utf-8. The formats of PDUs will be described in protocol documentation, sure. I am just not sure how many types of PDUs will it consist of when it's done. Is we just leave as a data octet stream, any kind of PDU added later would not break the initial design. That's just my point of view, maybe you disagree and I respect that. Sometimes you can't now in advance all the possible extensions that might follow later on, lime EtherType for example. I'm sure that initial version didn't include all the values available today. No disrespect and sorry if I sound a bit rude, I would just like to get this DLT as soon as possible and also define a simple easily extendable header. Cheers On May 11, 2019 11:27:57 PM GMT+02:00, Guy Harris wrote: >On May 11, 2019, at 1:39 PM, Damir Franusic >wrote: > >> Like I sad, I don't have the complete documentation ready, > >When you have the complete documentation ready, let us know. > >> but this is the general format: >> >> +-+ >> | Version | >> | (1 Octet) | >> | | >> +-+ >> | PDU Type | >> | (1 Octet) | >> | | > >What are the PDU type values? > >> +-+ >> | Source ELLE Node | >> | NULL terminated ASCII string | >> | (1 Octet min for \0) | > >So that's pure ASCII, without, for example, any letters with >diacritical marks, so it doesn't need full UTF-8? > >> | | >> +-+ >> | Destination ELEE Node | >> | NULL terminated ASCII string | >> | (1 Octet min for \0) | > >And the same applies there? > >> | | >> +-+ >> | ELEE PDU Payload | >> . (Remaining octets) . >> . . >> . . >> >> PDU Payload part is the rest of the packet data >> and will be interpreted based on PDU Type. > >Presumably the formats of the PDU payloads will be described in the >complete documentation. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New official link-layer type request
No problem, I will do my best to describe the current version, you'll get it tomorrow. Thank You for being so prompt On May 12, 2019 12:02:42 AM GMT+02:00, Guy Harris wrote: >On May 11, 2019, at 2:51 PM, Damir Franusic >wrote: > >> PDU types are extendable and there might be more of them in the >future. I wanted to make it like this so adding new types would not >present a big issue. I can define the two PDU types used at present >moment but maybe it would be more practical to leave PDU payload part >as generic octet stream if that's possible. > >Why would it be more practical not to define *what you already >implementString s are pure ASCII C null terminated, no need for utf-8. > >> The formats of PDUs will be described in protocol documentation, >sure. I am just not sure how many types of PDUs will it consist of when >it's done. Is we just leave as a data octet stream, any kind of PDU >added later would not break the initial design. > >If you're planning on extending this, then what you should do is: > > put a specification for the *current* set of PDU types on your Web >site, *including* the payload formats for each of those PDU types; > > update it as *new* PDU types are added; > >and the entry for your LINKTYPE_ value on tcpdump.org can link to that >specification. > >pcapng has a specification: > > > http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-tuexen-opsawg-pcapng.xml&modeAsFormat=html/ascii&type=ascii > >and it *does* list the block type values, and formats, for existing >block types, and the option number values, and formats, for existing >options, but that does *not* prevent it from being extensible; as new >block types or options are added, the specification is updated. > >Our goal is to have a registry of link-layer header types that would >allow somebody to write their *own* code to process pcap or pcapng >files with packets of that type *without* having to read tcpdump or >Wireshark code to figure out how to analyze it. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
