Monday, October 19, 2020

OSS ASN.1 Studio Test Data Generator

Having spent three decades developing robust and reliable ASN.1 solutions, we know how time consuming and complex a task it is to create a comprehensive test suite to test your own ASN.1-based solutions. This is why ASN.1 Studio, our powerful state-of-the-art ASN.1 IDE, includes a powerful feature that allows you to easily configure it, and within seconds  to generate thousands of different test messages  - work that, if performed manually, would be error prone and take days or weeks to complete.


ASN.1 Studio includes several options to customize your test messages. As you can see in the image above, if constraints are applied to ASN.1 types or on the fields of a type, you can select the first value that satisfies the constraints, or select a random value using those constraints. You can also ignore the constraints and set possible values in a configuration table for the ASN.1 types and fields that ASN.1 Studio will then use to generate test messages. 

Following are a few examples of values and ranges of values for various ASN.1 types or fields that you can configure for the test message generation. 


  • For INTEGER types, you can select a range of values. 


  • You can select TRUE, FALSE, or a random value for BOOLEAN types. 


  • For OCTET STRING types, you can select the minimum and maximum length of octets, and the range for a single octet value; that is, you can specify that all the octet values should range from 0x00 to 0x1F.


  • For OBJECT IDENTIFIER types, you can specify the root arcs, a value range for additional arc values, and the number of additional arcs. 


  • For values of REAL types, you can specify ranges for mantissa values and exponent values to be used in the test messages. 


  • For optional field values in SEQUENCE/SET types, you can select Absent, Present, or Random. You can do the same for the DEFAULT and extension addition values. For SEQUENCE OF/SET OF types, you can specify the number of components. 


  • Similarly, you can specify the values for several other ASN.1 types, such as BIT STRING, CHOICE, ENUMERATED, OID-IRI, Relative-OID, Relative-OID-IRI, REAL, Recursive types, Time types, and unrestricted character string types.


The current version of ASN.1 Studio saves all newly created test messages in one file. The next release will support saving such messages in separate files.


All of our ASN.1 Tools include ASN.1 Studio. Download a trial version of the OSS ASN.1 Tools and learn more about the test message generation feature by reviewing the “How do I create one or more encoded messages” section of the ASN.1 Studio Help screen. If you have any questions about the test message feature or ASN.1 Studio, please contact us at support@oss.com.


Monday, October 12, 2020

RTOED Runtime Library

With the release of ASN.1/C Tools 11.0 and ASN.1/C++ Tools 7.0, OSS introduces a new runtime library – RTOED (Read-only function pointers TOED). It is an enhanced version of TOED, OSS’ high performance, time-optimized runtime library.

RTOED includes several new features:

• The few function pointers used in RTOED are declared as static const. When RTOED code is compiled, the C compiler will place the function pointers in your program’s read-only memory, thereby preventing them from being maliciously overwritten to alter the control flow.

• The RTOED, TOED, SOED, and LED runtime libraries all now employ an improved stack protection mechanism to handle error conditions.

• If supported by your platform, ASN.1/C TOED and RTOED can be built using secured C runtime functions as specified in Annex K of the ISO/IEC 9899 standard, Information technology — Programming languages — C. This feature will be available in ASN.1/C++ TOED and RTOED in the next release, available 1Q2021.

RTOED static runtime libraries are now included in OSS’ ASN.1/C and ASN.1/C++ Tools. Existing TOED customers can easily upgrade to RTOED. In most cases (see RTOED limitations), you won’t need to change your application code; just recompile your ASN.1 specification with the -rtoed ASN.1 compiler option and re-link with the new RTOED library.

ASN.1 Studio, our state-of-the-art ASN.1 IDE, includes a powerful feature that offers easy configuration; within seconds you can generate thousands of different test messages. This is work that, if performed manually, would be error prone and take days or weeks to complete.

Thursday, January 2, 2020

What's New in 2020 - OSS ASN.1 and NAS Tools


2020 is going to be an exciting year for our customers. We will update our ASN.1 and NAS Tools to support 3GPP LTE and 5G Releases 15 and 16. In addition to enhancing our existing tools with new value added features, we will also introduce new NAS/C# Tools for LTE and 5G as well as our new S1/X2 ASN.1 API for Java.

The ASN.1 Tools will be upgraded to support LTE and 5G Releases 15 and 16. The OSS NAS/C, NAS/C++, and NAS/Java Tools, and NAS-1Step will be available for LTE and 5G Release 16.

Following the success of our NAS/C, NAS/C++, NAS/Java and NAS-1Step Tools, we are releasing the first version of our NAS/C# Tools available for LTE and 5G Release 16 in the second half of 2020. Users will be able to serialize/parse NAS messages from/to C# objects. In addition, the Tools will provide direct conversion of NAS messages to XML or JSON format. 

This year OSS is releasing our new S1/X2 ASN.1 API for Java supporting LTE Releases 14 and 15. This API will significantly reduce your S1/X2 protocol implementation efforts and provide an easier and less error prone upgrade path to newer 3GPP Releases. In addition, OSS will be updating the existing S1/X2 ASN.1 APIs for C and Java to support LTE Release 16 in 3Q2020.

ASN.1 Studio will be enhanced to automatically create several messages based on an input ASN.1 specification. This feature is particularly useful for customers when testing, as it will automatically generate several different types of test messages for their specification.

The ASN.1/C# Tools will support partial decoding to enable you to quickly decode preselected fields from incoming messages. A significant advantage of using partial decoding is that, when looking for a particular component in a large message, you can directly receive the value of the component you are looking for without having to navigate through the large message structure. This feature is useful in many application areas including Lawful Intercept, routers, protocol analyzers, and Self-Organizing Networks (SON).

3GPP is currently working on Release 16 which is expected to be finalized by June 2020. This Release will include support for Multimedia Priority Service, Vehicle-to-everything (V2X) application layer services, 5G satellite access, Local Area Network support in 5G, wireless and wireline convergence for 5G, terminal positioning and location, communications in vertical domains, network automation, and novel radio techniques, etc. The OSS ASN.1 Tools will support Release 16. New samples will be added and existing samples will be updated to demonstrate how Release 16 ASN.1 based protocols can be used with the OSS ASN.1 Tools.



3GPP Protocol Based Products
Availability
3GPP LTE Release 15 Support
3GPP LTE Release 16 Support
3GPP 5G Release 15 Support
3GPP 5G Release 16 Support
NAS/C LTE
Now
1Q2020
N/A
N/A
NAS/C 5G
N/A
N/A
Now
2Q2020
NAS/C++ LTE
Now
1Q2020
N/A
N/A
NAS/C++ 5G
N/A
N/A
Now
2Q2020
NAS/Java LTE
Now
1Q2020
N/A
N/A
NAS/Java 5G
N/A
N/A
Now
3Q2020
NAS-1Step LTE
Now
1Q2020
N/A
N/A
NAS-1Step 5G
N/A
N/A
Now
2Q2020
NAS/C# LTE
N/A
3Q2020
N/A
N/A
NAS/C# 5G
N/A
N/A
N/A
3Q2020
S1/X2 ASN.1 API for C
Now
3Q2020
N/A
N/A
S1/X2 ASN.1 API for Java
1Q2020
3Q2020
N/A
N/A

N/A - Not Applicable



Thursday, October 3, 2019

At the beginning there was a schema.


Recently we developed a simple “in house” JSON-based protocol for fetching user details from a directory, where apps would submit a ticket (a string identifying a user) to get user info. For example:
app request
server response
{ ”ticket” : ”T9yIC4c2mzR” }
{
   "authorized" : true, 
   "name" : "John Johnson", 
   "email" : "jj@....", 
   "licenses" : [....]
}  

To communicate in JSON we utilized our own DCodec library, which is capable not only of JSON serialization, but also of JSON validation against an ASN.1 schema when one is provided. So we defined this ASN.1 schema:
UserInfo ::= SEQUENCE 
{
  authorized  BOOLEAN DEFAULT FALSE, 
  name        UTF8String (SIZE (3..161)),
  email       UTF8String (SIZE (5..100)),
  licenses    SEQUENCE (SIZE (0..MAX)) OF License
}
...

Since the protocol was simple, the schema was not mandatory (some nodes couldn’t use it even if they wanted to), but it was convenient as informal documentation for developers (defining the message structure, field optionality, value ranges, defaults, etc), as well as for message validation. Yet, there were a few more benefits of having a schema, which we realized only after we implemented it

The logic for handling the UserInfo.authorized field appeared to be very simple: the user is authorized only when the field is set to TRUE, while in all other conditions, including when something is wrong with the message (e.g. wasn't received), would result in a non-authorized user. Such logic proved correct during testing, so the code went into production.

While in production, on rare occasions, we noticed that some responses included an extra field (a way for the directory server to tell about an internal problem):
{
   "error" : 5,
   "authorized" : false, 
   "name" : "", 
   "email" : "", 
   "licenses" : []
}  

We’d never have caught the problem of a message carrying an extra field if not for the “invalid message” events logged due to the schema mismatch, since from the app point of view there was nothing wrong, and the user just appeared to be “non-authorized”, so there was no visible interruption.

Hence we updated the schema to allow a new field “error”, but we immediately caught another schema mismatch. This time it was for “name” and “email” SIZE violation, which cannot be empty. This time we realized that we’re re-using a single message for different cases - success and failure of fetching user info. So we changed the schema one more time to add a new message type for errors:
Response ::= CHOICE 
{
  user  UserInfo, -- successful response
  error Error     -- unsuccessful response
}

UserInfo ::= SEQUENCE 
{
  authorized  BOOLEAN DEFAULT FALSE, 
  name        UTF8String (SIZE (3..161)),
  email       UTF8String (SIZE (5..100)),
  licenses    SEQUENCE (SIZE (0..MAX)) OF License
}

Error ::= SEQUENCE
{
  code        INTEGER (0..255), 
  description UTF8String (SIZE (0..256))
}
Now the response could be either user info, say:
{"user":{"authorized":true, "name":"John Jonson", .... }}
or an “error”, like:
{"error":{"code":5, "description":"...."}}

Without the schema we could have just patched the app code (as “it’s not my problem”) by either ignoring the error, or allowed empty fields, or custom-handled every issue somewhere and somehow. Doing so would result in masking the problem and/or spreading the validation logic all over the application stack.

Another not-so-obvious benefit of using a schema is that the data definition could be stored together with the app sources, so data become a versioned part of Infrastructure as Code, Continuous Integration and Continuous Deployment - following the best practices of DevOps.


WITH SCHEMA
  • Clear boundary of data validation, when the data just entered the system (layer, node).
  • Catch the problem early.
  • Data and code are in sync, defined and implemented together.
  • Precise logic for data definition/validation.
WITHOUT SCHEMA
  • Debug the entire app stack to pinpoint the data at consumption location.
  • Vendor-specific validation logic.
  • Certain conditions might be left unchecked/undetected (e.g. outside the app logic).