Comments on APC-1280

Karl Klaghofer karl.klaghofer at MCH.PN.SIEMENS.DE
Wed Aug 27 07:15:50 EDT 1997


Dear Jim,

I had a chance to read (actually look) through APC-1191 (Hertzlia
meeting document) and found some presumable editorial errors as
attached from a bystander perspective.  This might be too late for
your Sunriver input, but I hope it would be of some use for your
further editing.  { } indicates my thoughts.

I have a couple of questions other than THE editorial comments for my
understanding.

1) General

H.235 seems to be handling only media by media encryption.  The case
of encrypting H.222.1 multiplexed stream or H.223 multiplexed stream
is also covered by the current specification?  Or can it be part of
the future H.235 extension?

2) Section 9.2, nonIsoMediaEncryptionAlgorithm   ::=CHOICE
   Section 13.3.5, nonIsoIdAlgorithm     ::=CHOICE

We have three such non-ISO algorithms specifically listed.  Is this
the policy we confirmed?  Are we going to list all of proprietary
algorithms one by one in H.235 (or H.225.0, H.245)?  Or are they
identified in non-standard ways?

3) Section 9.2, ASN.1 syntax

H.245 syntax has a top-down structure, but here it looks bottom-up.
{Perhaps either way is alright for encoding and decoding?}

Best regards,

Sakae OKUBO (Mr.)
********************************************************************
Graphics Communication Laboratories       Phone:  +81 3 5351 0181
6F ANNEX TOSHIN BLDG.                     Fax:    +81 3 5351 0184
4-36-19 Yoyogi, Shibuya-ku, Tokyo         e-mail: okubo at gctech.co.jp
151 Japan
********************************************************************

Source: Sakae Okubo
Title:  Ecitorial comments on APC-1191 Draft H.235
Date:   27 August 1997

1.      Contents

title of 13. ==> H.323 SPECIFIC TOPICS
title of 14. ==> H.324 SPECIFIC TOPICS

2.      Section 2, Item 4

The last sentence "This may include both the number of secured users
and the levels of security provided." is duplicated.

3.      Section 2, Item 6

Period is missing at the end.

4.      Section 7.1, Items IV. and V.

OpenLogicalCahhnel, OpenLogicalChannelAc, EncryptionUpdateRequest,
EncryptionUpdate ==> in bold {?}

5.      Section 7.1.3, second sentence

on a channel by channel basis ==> on a logical channel by logical
channel basis {?}

6.      Section 7.2, 2nd paragraph, 4th sentence

the card is always may always be ==> one of them should be deleted
{may be due to my reading the document on Mac Word}

7.      Section 7.2.1, 2nd paragraph

H.Secure ==> H.235

8.      Section 7.5, 1st paragraph, "any entity which terminates a
call control channel (H.245) "

{There are several places where "call control" is associated with
H.245, but Q.931/Q.2931 is more appropriate for the call control.
H.323 says H.245 control, call control H.225.0 and RAS control H.225.0
as part of the system control in Figure 4.  So, H.245 control channel
may be the replacement, otherwise communication control may be the
choice according to the title of Rec. H.245.}

9.      Sections 7.5.2 and 7.5.3

They should be transposed {?}

10.     Section 8.1, 1st paragraph

See #8.

11.     Section 9.1, 1st paragraph

The first sentence needs a period at the end.

12.     Section 9.1, 2nd paragraph

"scope (in italic)" is used with a security specific meaning.  I would
suggest this should appear in Section 4 Definitions.  We have general
"scope" in other places.

13.     Section 9.3, 2nd paragraph, 2nd sentence

It is hard to understand this sentence; notions of "inclusive and
exclusive" and "encrypted codes" in particular.

14.     Section 11.1, 3rd sentence

I cannot find "prepend" in my dictionaries.

15.     Section 11.3, overall

The style is something like a discussion contribution.  We need to
change it to that of specification.

15.     Section 11.3, Item I. A. Initialization vectors, 2nd last
sentence

What is "B" octets?

16.     Section 11.3, Item I. B. Padding, 2nd paragraph, "Two methods
are proposed to handle packets ..."

"proposed" is strange in Recommendation.

17.     Section 11.3, Item I. B. Padding, 4th paragraph

There is a spurious period.

18.     Section 11.3, Item I. B. Padding, 5th paragraph

- H.Secure ==> H.235
- "It is recommended that all H.Secure implementations must support
..." must ==> should {?}

19.     Section 11.3, Item I. B. Padding, 5th paragraph

What is "P" bit?  See also #15.

20.     Section 11.3, Item Stream Algorithms

The item number ==> II.

21. Section 11.3, after Item II. A. (spurious)

and if the performance problem is not deemed to be exist, it should
not be included. ==> to be existing, or to exist

22.     Section 13.1, Figure, TLS/SSL

SSL is striked out in Section H.245Security.  If it is valid, it
should appear in Section 5. Symbols and Abbreviations.

23.     Section 13.3.1, 2nd paragraph, 2nd sentence

The intent (as stated in section 7.2) is to not provide absolute, ==>
is not to {?}

24.     Sections 13.3.2, 13.3.3, 13.3.4

There are several "shared secret" in this section.  ==> shared secret
key {?}

25.     Appendix B, 3rd paragraph

SSL appears.  See #22.

26. Appendix E, 1st paragraph

"call control" appears.  See #8.

27.     Appendix E, 2nd and 3rd bullets

TLS/SSL appears.  See #22.

28.     Appendix E, Item III. Call Control (H.245)

See #8.

29.     Appendix E, Item 1b), 3rd sentence

Some of the RAS messages are multicast by definition, and as such is
would be impractical to make confidential. ==> either of "is" or
"would be" is spurious.

30.     Appendix E, Item 1b), 4th sentence

Call establishment messages are currently carried on UDP (unreliable)
transport Possible solutions ... ==> Call establishment messages are
currently carried on UDP (unreliable) transport.  Possible solutions
...

31.     Appendix E, Item 1c)

H.Secure ==> This Recommendation, or H.235

32.     Appendix E, Item 1c), last sentence

... using a "per-message randomization" in section Non-registration
RAS signaling 13.3.4. ==> ... using a "per-message randomization" in
section 13.3.4 Non-registration RAS signaling. {?}

33.     Appendix E, Item 3a)

... as provide in TLS/SSL. ==> ... as provided in TLS/SSL.

See also #22.

34.     Appendix E, Item 3b)

Bystanders able to snoop media encryption algorithms and keys
exchanged by participants loss of 4b, 4c and 4d. ==> Some words are
missing between participants and loss {?}

35.     Appendix E, Item 4c)

Denial of service attack if bystanders, 'scramble' data. ==> the comma
is unnecessary {?}

36.     Appendix E, Item 4c), last sentence

Integrity servies for media data is ... ==> Integrity service for
media data is ... or Integrity services for media data are ...

37.     After Appendix F

There are five definitions.  These should be moved to Section 4.  Or
are they a part of Appendix F?

---------< Thank you for your attention. >---------



More information about the sg16-avd mailing list