Re: ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Guy Harris <gharris () sonic net>]

On Jun 27, 2021, at 6:36 AM, Vincent Randal <vtrandal () gmail com> wrote:

> On Sat, Jun 26, 2021 at 9:41 PM Guy Harris <gharris () sonic net> wrote:
>
> > So this isn't really a Wireshark dissector question, it's a protocol design and encoding question.
>
> I'd like it not to be an encoding question beyond this: Given I'm using ASN.1 to generate dissectors (for the 
> protocols I am designing), which encoding can I use so that I can "see" my messages in the raw data?

In other words, you don't care about wasting ports?

And what do you mean by "see"?

> > The issue isn't "how do I get a Wireshark dissector to distinguish between different message types without giving 
> > each message type its own UDP port", it's "how do I get *the recipient of the messages* to distinguish between 
> > different message types without giving each message type its own UDP port" - this would be an issue even if there 
> > were no such thing as packet analyzers, because you'd be wasting the ports even if there were no packet analyzers.
>
> At this stage Wireshark is the only recipient of these messages that I care about.

I suspect the people developing and testing the receiver side of the protocol implementation care about more than that, 
even if you don't.

> I send the messages using Python asn1tools and receive them using tshark (perhaps also using Lua soon).

No, you *capture* them using TShark.  Does nobody have any programs that have the multiple ports in question open, and 
to which the Python program sends them?  (No, TShark does not have those ports open; it receives the packages by 
passively snooping network traffic, whether in promiscuous/monitor mode so that it can see "third-party" traffic or on 
the machine to which the packets are being sent so that promiscuous/monitor mode is not necessary.)

> > And it's best thought of not as a question of "using the first octet" as a question of "somehow encoding the message 
> > type in the message itself" - with Anders' suggestion of a change to the protocol, in BER, the first octet would 
> > contain information other than just the ClassNumber for the item in the CHOICE, and in PER, with the UNALIGNED 
> > variant, the ClassNumber would be encoded in the minimum number of bits needed to encode the range of ClassNumbers.
>
> I am using PER (apparently the ALIGNED variant) because (so far) I can "see" the messages in the raw hexadecimal 
> dump. I want a “null” encoder with this property: pre-encoded message byte = encoded message octet.

"Ability to see certain parts of the message easily in a hex dump" is generally not used as a design criterion for 
protocol encodings, but whatever.

> > The good news is that, if you generate the protocol implementation from the ASN.1, that will all be done for you - 
> > you won't have to write
>
> I’m not finding freely available tools that finish the job. I’m writing my own tools to fill in the gaps. My tools 
> generate ASN.1 from IEEE source documents (which they update after testing).

So what language are the IEEE source documents using, i.e. what language is the *IEEE* using to describe the protocol?

> > the code to parse the encoding of the value, esnacc (which translates from the IDL, ASN.1, *to* code, it doesn't 
> > translate ASN.1 to an IDL) will do that for you.  The same is true of Wireshark's
>
> Guy, look at "esnacc -idl" [I merge the output of "esnacc" and "esnacc -idl" to create an IDL that passes "omniidl" 
> syntax checking. I give a variant of this IDL to the IEEE for use as their message descriptions.]

Wait.

So you're using eSNACC to translate from one description language - ASN.1 - to *another* description language - CORBA 
IDL?  And the *latter* is what the IEEE are going to use when they publish the specification for the protocol, *not* 
ASN.1?

Note that CORBA IDL has its *own* encoding rules, different from the various types of rules that ASN.1 has.  See, for 
example, section 9, "General Inter-ORB Protocol", in Common Object Request Broker Architecture (CORBA) Specification, 
Version 3.3 Part 2: CORBA Interoperability:

        https://www.omg.org/spec/CORBA/3.4/Interoperability/PDF

Apparently, there are other flavors of inter-ORB protocol:

        https://en.wikipedia.org/wiki/General_Inter-ORB_Protocol

so there may be other encodings.

So, if the IEEE is going to publish the protocol that you're developing as a specification in the CORBA IDL language, 
rather than in the ASN.1 language, what will the *IEEE* expect to be the on-the-wire encoding?  *That* is ultimately 
what senders and receivers of these messages will have to implement, and what Wireshark will have to decode.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe