H.225.0/RAS ICV calculation

Paul Long plong at SMITHMICRO.COM
Wed Jun 24 16:18:34 EDT 1998

Pekka Pessi wrote:
>         The issue prevents interoperability between software using H.225.0
>         version 2 and software using any version, it should be solved before
>         any version 2 devices are released.

I have raised the issue of compatibility between versions here before,
but nobody except me seems to think that it will be a problem. Time will

>    However, there is a serious problem: the
>    canonical representation changes if the ASN.1 SEQUENCE type is extended
>    later.

Correct, a SEQUENCE type must be defined as extensible starting with the
first version in which it is defined if it is felt that it may need to
be extended in the future. Once a SEQUENCE type is defined to be NOT
extensible (there is no extension marker present), it cannot later be
extended without changing the encoding. For example, the ICV type can
never be extended.

> PER Encoding of an Extended ASN.1 SEQUENCE
>    In the PER encoding of extensions to SEQUENCE types, the encoder first
>    encodes the number of extensions as a normally small non-negative
>    integer, then a bit field with one bit for each extension followed by the
>    extensions itself (bit is one if the extension is present, zero if
>    not). The encoding of each extension is preceded by the length of their
>    encoding in octets.
>    Now, if the sender A uses following ASN.1 definition for a SEQUENCE
>       Foo ::= SEQUENCE
>       {
>            bar                 INTEGER (0..127),
>            ...,
>            baz                 INTEGER (0..255) OPTIONAL,
>            integrityCheckValue ICV OPTIONAL
>       }
>    When encoding this, the length of extension bitfield is 2.  However,
>    recipient B is using extended version of Foo like this:
>       Foo ::= SEQUENCE
>       {
>            bar                 INTEGER (0..127),
>            ...,
>            baz                 INTEGER (0..255) OPTIONAL,
>            integrityCheckValue ICV OPTIONAL,
>            importantExtension  SomeType OPTIONAL
>       }
>    B decodes the Foo, removes ICV and encodes the packet again.  In the
>    resulting encoding, the length of extension bitfield is 3, and the ICV
>    that B regenerates is different that A generated and sent to B. B is not
>    able to interwork with systems using earlier version of the ASN.1 spec.

Why not? This is precisely what the H.225.0 and H.245 protocolIdentifier
is for--to indicate which version of the Recommendation the endpoint
supports. An endpoint must know what protocol versions the remote
terminal supports. For example, if an H.225.0v3 endpoint communicates
with a v2 endpoint, it knows that the v2 endpoint will not recognize any
of the extensions added since v2 and shall not therefore depend on any
v3 behavior on the part of the v2 endpoint. Likewise, the v2 endpoint
must be able to treat all v2 and subsequent endpoints as a v2 endpoint.
Basically, an extension cannot be added to the ASN.1 syntax of a
Recomendation that changes the semantics of the fields defined in the
previous version of the Recommendation. If this is done, we will have
serious interoperability problems.

> ASN.1 Compilers Don't Grok Unknown Extensions
>    There are also problems because the way some ASN.1 compilers behave.
>    Using our previous example, when A receives Foo with the
>    importantExtension field from B, A has somehow to include the value when
>    it is re-encoding Foo in order to calculate the ICV.

I can't think of a situation where a terminal would ever have to
re-encode. Are you referring to a GK or GW?

>    However, it may be
>    very hard to present an value of an unknown extension to the ASN.1
>    encoding functions.

We use our own ASN.1 codec, so this isn't a problem for us.

> Problems with Non-OPTIONAL Extensions
>    Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL
>    extensions. Let us assume that software C uses following ASN.1 definition
>    for Foo:
>       Foo ::= SEQUENCE
>       {
>            bar                 INTEGER (0..127),
>            ...,
>            baz                 INTEGER (0..255) OPTIONAL,
>            integrityCheckValue ICV OPTIONAL,
>            importantExtension  SomeType OPTIONAL,
>            criticalExtension   OtherType
>       }
>    There are two kinds of problems with an extension like criticalExtension.
>    First, the encoder may try to ensure that all encoded PDUs conform to the
>    specification and signal an error when a PDU without criticalExtension is
>    encoded.

IMO, this is correct behavior.

>    Another problem is that the intermediate representation produced
>    by the ASN.1 compiler may not provide means for application to express
>    that criticalExtension is not present. (In other words, the produced
>    structure usually contains a flag telling whether an optional field is
>    present or not. Such flags are not included when the field is not
>    optional.)

This makes sense to me because all version-N extension additions must be
_represented_ in the encoding if you are a version-N implementation, and
extension additions that are not optional must also be _present_--their
value must be encoded. Optional extension additions are always
represented by their corresponding bits in the bit field; if they are
present, their value is also encoded.

>    The presense or absence of the OPTIONAL flag in an extension does not
>    change the PER encoding of the SEQUENCE. In order to avoid previously
>    mentioned problems, application may use a version of ASN.1 notation that
>    has extra OPTIONAL keyword after each extension.

Some extension additions are defined as OPTIONAL and some not,
presumably for a reason. Indicating that a non-optional one is not
present would produce an encoding with a semantic error, while not an
encoding syntax error, per se.

> Solution 1: Clarification to the PER Encoding Process
>    The text in PER document (X.691, 1994) is somewhat ambiguous how many
>    bits should be included in the extension present bitfield of SEQUENCE. To
>    quote verbatim: "Let the number of extension additions in the type being
>    encoded be "n", then a bit-field with "n" bits shall be produced for
>    addition to the field-list." (Is the "type being encoded" the abstract
>    syntax or an actual value like { bar 1, baz 2 }?)

If you'll notice, X.691 is very careful about its use of "type" and
"value." Specifically, "abstract syntax value: A value of an abstract
syntax (defined as the set of values of a single ASN.1 type), which is
to be encoded by PER, or which is to be generated by PER encoding." I am
sure that X.691 is referring to, in our case, the ASN.1 syntax defined
in the version of the Recommendation identified by the

>    However, the 0 bits at
>    the end of extension present bitfield can be left out without changing
>    the resulting semantics: the corresponding extensions are not present. As
>    a result, the PER encoding does not change after a new extension is added
>    to the ASN.1 specification.

Syntactically, one could leave out the last N extension additions
(regardless of whether any are OPTIONAL, they are still represented in
some way); however, this would result in a semantic error because "a
bit-field with 'n' bits" was not "produced" where "n" is "the number of
extension additions in the type being encoded." Just as with a field in
the extension root, one may not simply choose to not encode an extension
addition that is defined in the version of the Recommendation that you
identify in your protocolIdentifier field.

>    This solution, while leaving H.225.0 v2 protocol as it is, requires
>    however changes to some existing ASN.1 compilers, and in a pessimal case,
>    to the X.691 standard text, too.

I see know reason to modify compilers or X.691. If one obeys the rules,
everything works. Clarification text may be needed, however.

Paul Long
Smith Micro Software, Inc.

More information about the sg16-avd mailing list