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@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@intel.com mailto:james.toga@itu.ch *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************