Re: [tcpdump-workers] New official link-layer type request

[Damir Franusic]

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  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-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]

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 R

Re: [tcpdump-workers] New official link-layer type request

[Damir Franusic]

Hi

I have read the specs for pcapng but then again I would have have to use 
The Simple Packet Block (SPB) or
An Enhanced Packet Block (EPB) and that would not solve my problem 
because of this:



Packet Data: the data coming from the network, including link-layer 
headers. ..The format of the data
within this Packet Data field depends on the LinkType field specified in 
the Interface Description Block
(see Section 4.2 
) 
and it is specified in the entry for that format in the tcpdump.org 
link-layer header types registry .



As I mentioned earlier, not all data is network packet data and when we 
send that LI specific event
data, there is no LinkType for that and that's why I'm asking for a new 
DLT to cover all this. Then I can
carry both encapsulated network data (tshark CC example) and unrelated 
LI event (tshark IRI example).



I will create a specification for ELEE (started already), no problem, I 
just wouldn't want to work on it if I get rejected

in the end because of not being clear what I need it for.



On 5/12/19 12:42 AM, Michael Richardson wrote:

Guy Harris  wrote:
 > 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.

Also, it might be that pcapng would actually be a really good container for
your work rather than inventing yet-another-TLV.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


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

[Damir Franusic]

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  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-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]

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   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


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

[Damir Franusic]

Hi Guy

I've tried to be as prompt and as accurate as possible so here is the 
draft, I hope you'll appreciate the effort. I agree
that the initial thing I sent was an abomination. I will work on this 
draft as the project progresses, but for now, it covers

everything implemented so far.

http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=http://socket.hr/draft-dfranusic-elee-00.xml&modeAsFormat=html/ascii


On 5/11/19 11:30 PM, 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.


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

[Guy Harris]

On May 12, 2019, at 1:28 PM, Damir Franusic  wrote:

> I've tried to be as prompt and as accurate as possible so here is the draft, 
> I hope you'll appreciate the effort. I agree
> that the initial thing I sent was an abomination. I will work on this draft 
> as the project progresses, but for now, it covers
> everything implemented so far.
> 
> http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=http://socket.hr/draft-dfranusic-elee-00.xml&modeAsFormat=html/ascii

So a packet with the requested new LINKTYPE_ value would consist of an ELEE 
header, followed by an ELEE PDU, and that's it?

We could then just have the entry on the tcpdump.org link-layer header types 
point to the draft, so that if you add new PDU types, the draft will be 
updated. If the draft ends up being published as an official I-D, we could 
point to that and, if it becomes an RFC, point to that.
___
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

[Damir Franusic]

That would be great thanks. That's all I ever wanted really, but now I 
understand the relevance of having a proper I-D.  And yes, you are correct 
regarding the Header/PDU; quite simple.

On May 12, 2019 10:38:21 PM GMT+02:00, Guy Harris  wrote:
>On May 12, 2019, at 1:28 PM, Damir Franusic 
>wrote:
>
>> I've tried to be as prompt and as accurate as possible so here is the
>draft, I hope you'll appreciate the effort. I agree
>> that the initial thing I sent was an abomination. I will work on this
>draft as the project progresses, but for now, it covers
>> everything implemented so far.
>> 
>>
>http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=http://socket.hr/draft-dfranusic-elee-00.xml&modeAsFormat=html/ascii
>
>So a packet with the requested new LINKTYPE_ value would consist of an
>ELEE header, followed by an ELEE PDU, and that's it?
>
>We could then just have the entry on the tcpdump.org link-layer header
>types point to the draft, so that if you add new PDU types, the draft
>will be updated. If the draft ends up being published as an official
>I-D, we could point to that and, if it becomes an RFC, point to that.

-- 
Damir Franusic

http://socket.hr
http://github.com/dfranusic
___
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

[Guy Harris]

On May 12, 2019, at 1:48 PM, Damir Franusic  wrote:

> That would be great thanks. That's all I ever wanted really, but now I 
> understand the relevance of having a proper I-D.

It will also be useful for documenting the protocol when run over SCTP.

Are you planning on running the protocol through the IETF standards process:

https://www.ietf.org/standards/process/

or did you just use the I-D format for convenience (or because that's how the 
pcapng spec is being done - we may submit it as an I-D at some point)?

> And yes, you are correct regarding the Header/PDU; quite simple.

Great - thanks!  So shall we link to that draft, for now?
___
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

[Damir Franusic]

Hi

I used I-D since It's still work in progress. And yes, I also looked at pcapng 
and assumed I couldn't go wrong with following those guideline s. I've never 
written an RFC or I-D so using pcapng draft seemed like a good starting point.

I plan to document the SCTP part also and when it's all done, I would lilke to 
eventually get it published as an RFC. 

You can link it to the draft for now, and I will continue to update it. When 
the time comes and I'm satisfied will the final version, I will let you know. 
You know a lot about this RFC process than I do.

Thank You again for all the help

On May 12, 2019 11:00:16 PM GMT+02:00, Guy Harris  wrote:
>On May 12, 2019, at 1:48 PM, Damir Franusic 
>wrote:
>
>> That would be great thanks. That's all I ever wanted really, but now
>I understand the relevance of having a proper I-D.
>
>It will also be useful for documenting the protocol when run over SCTP.
>
>Are you planning on running the protocol through the IETF standards
>process:
>
>   https://www.ietf.org/standards/process/
>
>or did you just use the I-D format for convenience (or because that's
>how the pcapng spec is being done - we may submit it as an I-D at some
>point)?
>
>> And yes, you are correct regarding the Header/PDU; quite simple.
>
>Great - thanks!  So shall we link to that draft, for now?

-- 
Damir Franusic

http://socket.hr
http://github.com/dfranusic
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers