H.225.0/RAS ICV calculation

[Jim Toga]

Pekka,

Ok... I think we're both right (maybe you, more than me....)

The extentions do not change any of the encoding of the base structure.  If
the ICV is figured on these field values only, then it will not change no
matter what the encode of extention entries.  This obviously only protects
the integrity of v1 fields in RAS messages. Suboptimal.

In terms of checking the ICV (given the above) the receiver can simply
compute the ICV on the encoded PDU and check it against the value that was
passed in the PDU.  The ICV is generated on the wire encoded value and
excludes/initializes the field it is stored in... so I still don't see the
problem here.

As to the more pressing extention field problem.... I guess I was thinking
all along that you #3 explanation (previous mail) was the way things would
work in general.  Maybe Martin Euchner (Siemens) the source of this
particular functionality in H.235 would care to comment.

Regards,

jimt.

At 03:49 PM 6/25/98 +0300, Pekka Pessi wrote:
>"EXT Jim Toga" <jim.toga at intel.com> writes:
>>I'm confused by a couple of your statements.
>
>>The presence of the extention markers is included in the PER encoding (by a
>>single bit at the beginning) but the addition of extentions at a later
>>time should not change any of the encodings of the 'base' structure.  Any
>>extentions that are added, end up following the PER structure and are
>>actually encoded as BER 'chunks' so that earlier revisions of the protocol
>>may skip over the ones not understood.
>
>       Well, this is slightly incorrect.  A SEQUENCE type with extension
>       additions is encoded as follows (see X.691 paragraphs 18.6 - 18.9):
>
>       * extension marker at the beginning of SEQUENCE is encoded as 1 bit
>
>       * the base structure is encoded
>
>       * number of extensions is encoded as "normally small length"
>
>       * a bit field with a bit for each extension is encoded
>         (bit is one if the extension is present, zero if not)
>
>       * present extensions are encoded as open type fields, i.e., normal
>         PER encoding of the extension addition preceded by its length as
>         octets
>
>       Here is a concrete example (I hope).  There are two ASN.1 SEQUENCEs
>       like this, one from hypothetical version 2, second from version 3:
>
>Byte ::= INTEGER (0 .. 255)
>
>Type-v2 ::= SEQUENCE
>{
>  foo Byte,
>  ...,
>  bar Byte OPTIONAL
>}
>
>value-v2 Type-v2 ::= { foo 85, bar 170 }
>
>Type-v3 ::= SEQUENCE
>{
>  foo Byte,
>  ...,
>  bar Byte OPTIONAL,
>  baz Byte OPTIONAL
>}
>
>value-v3 Type-v3 ::= { foo 85, bar 170 }
>
>       We encode value-v2 and value-v3 with PER.  Results look like this:
>
>80 55 01 01 aa
>80 55 03 00 01 aa
>
>       I'll go through the structure of value-v3:
>
>hex    binary
>80     1xxxxxxx        Extension bit (1 means that there are some
>                       extensions present) followed by 7 bits for alignment
>55     01010101        foo 85
>03     0000001         number of extension additions minus 1 = 1
>              1        first bit of bitfield, indicating "bar" is present
>00     0xxxxxxx        second bit of bitfield, indicating "baz" is not
>                       present, followed by 7 bits for alignment
>01     00000001        lenght of "bar" in octets
>aa     10101010        bar 170
>
>       As you notice, the second addition, baz, changed the encoding even
>       if it is not present in the SEQUENCE!
>
>>I'm confused as to your example of encoding - decoding - re-encoding  The
>>ICV _will_ have to be recalculated.  The ICV is calculated after the ASN.1
>>structure is fully encoded (but excluding the ICV field itself) and just
>>before it is sent out 'on the wire'.  The ICV value may in fact change
>>value, and even position, but it should always be recognized by rev2 and
>>newer implementations.  Rev1 obviously will ignore it and not generate one
>>to send out....
>
>       Receiver must decode the PDU, re-encode the PDU without ICV,
>       calculate the ICV over the re-encoded PDU and compare the result
>       with the ICV from decoded PDU.  If the ASN.1 version that receiver
>       has (like Type-v3 above) differs from the version that sender has
>       (like Type-v2 above), the re-encoded PDU differs from the PDU over
>       which the sender calculated ICV.  Naturally the ICV also differs.
>
>       I hope this cleared some confusion.
>
>                                       Pekka Pessi
>
>
>

*****************************************************
***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
    ***
***  mailto:jim.toga at intel.com         mailto:james.toga at itu.ch         ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
*****************************************************