Improving the ASN.1 UPER Parser for srsRAN Project

[zhouxt1]

The current ASN.1 UPER decoder (for RRC layer) is overly lenient and accepts various non-canonically encoded or invalid messages without raising an error. This can mask interoperability issues with other vendors or non-compliant UEs. For a robust implementation, the decoder should be capable of strictly validating incoming messages against the ASN.1 and UPER specifications.

The following are specific examples of issues observed:

INTEGER Constraints

• Rule: An INTEGER defined with a value range (e.g., INTEGER (0..15)) should only accept values within that range.
• Observed Behavior: The decoder may successfully parse a message containing an out-of-range integer value without reporting an error. This issue is mentioned in ASN.1 Compiler Possible Improvement: Integer Constraint Check #1168.

SIZE Constraints

• Rule: A SEQUENCE OF or OCTET STRING with a SIZE constraint (e.g., SIZE (1..5)) must conform to that length constraint.
• Observed Behavior: The decoder may successfully parse a message where the number of elements or octets is outside the defined SIZE range.

Invalid Extension Values in Non-Extended Messages

• Rule: If a CHOICE or ENUMERATED type is extended, its extended values can only be used if the parent PDU itself is an extended version (i.e., its extension bit is 1).
• Observed Behavior: The decoder may parse an extended CHOICE or ENUMERATED value even when the parent PDU's extension bit is 0. This is because the tag was oveflowed, which points to a non-existant choice, then the parser simply fills it with a choice in the extension, other than rejecting the message.

There are also some minor issues, which only matters if the parser is designed to be very strict.

Unconstrained INTEGER Encoding

• Rule: Per ITU-T X.691 (11.3.6), an unconstrained integer must be encoded using the minimum number of octets.
• Observed Behavior: The decoder accepts integers with redundant leading octets (e.g., a value of 255 encoded as 0x02 0x00 0xFF instead of the canonical 0x01 0xFF). Similar issue is for length determinant.

Explicit Encoding of DEFAULT Values

• Rule: Per X.691 (19.5), the encoding for a component with a DEFAULT value must be absent if its value is the default for a simple type.
• Observed Behavior: The decoder accepts messages where a simple type's default value (e.g., INTEGER DEFAULT 0) is explicitly encoded rather than omitted.

Empty Extension Groups

• Rule: Per X.691 (19.9), if an extension bit is set to 1 in the bitmap, but all components within the corresponding extension group are absent, the encoding is non-canonical. The extension bit should have been 0.
• Observed Behavior: The decoder accepts a message where an extension bit is 1 but the extension group is effectively empty.

Is the ASN.1 parser designed to be lenient to make it faster, or should it be stricter?

The other question is whether there is any plans to release the ASN.1 compiler as discussed in #55?