comments on AVD 2253 from Raleigh
Robert R. Gilman
rrg at AVAYA.COM
Tue Sep 17 15:50:16 EDT 2002
Paul-
With respect to the security (i.e., encryption) of the various payloads
in a "bundled" stream, there are several items we should consider:
1. It's much more convenient to presume that all payloads are encrypted
under the same algorithm with the same key. This typically means
that the RTP packets should carry successive sequence numbers and the
same SSRC.
2. We have either or both of two types of RTP packets: one payload type
per packet, and multiple payload types per packet. The payloads are
all negotiated, so they are predictable - the multi-PT packets are
RFC2198 encoded, and the encapsulating PT is set during negotiation.
3. When we're encrypting multiple payload types, and the payload type is
preempted for encryption sync, we should presume/infer/require that the
packet is encoded as per RFC2198, and the encryption payload is the
encapsulating payload type, with the actual PT (or types) included in
the body of the packet.
4. Inasmuch as the PTs can be inferred, in many cases, from the packet
length, it would make some security sense to exclude the encapsulated
payload headers from the encryption (this can be done because they all
appear before any of the payloads.) On one hand, this prevents a known-
plaintext attack; on the other, it might facilitate it if the content
for some payload type is predictable.
I'm sure Martin Euchner has some ideas about these items as well.
-Bob
----------------------------------------------------
Bob Gilman rrg at avaya.com +1 303 538 3868
"Paul E. Jones" wrote:
>
> Roni,
>
> ,
> > I have some concerns about the changes proposed in this AVD.
> >
> > 1. The AVD adds a new data type called multiplepayloadstream that is
> > intended to allow more then one payload in a stream. According to the
> ASN.1
> > you can have different media types in the same logical channel which is
> not
> > a good practice and would break a lot of implementations.
>
> We already have precedence for this, such as RFC 2833. In addition, this
> feature would only be used if both sides advertise the capabilities, so I do
> not expect to see anything break.
>
> > 2. The data type in H.245 open logical channel describe the media type but
> > do not specify the RTP payload format used. There are cases were there is
> > more then one way to build the RTP stream for example in H.263. In the OLC
> > in H2250LogicalChannelParameters there is a RTPPayloadType parameter that
> > describe the RTP payload. If the AVD is used to describe multiple streams
> > there is no way to specify the packetization scheme used.
>
> This might be true. Would it be possible to add those parameters as
> necessary in the future? At the moment, the only use for this capability at
> the moment is for modem over IP, wherein every payload that will be used is
> understood based solely on the capability, I believe-- perhaps I'm wrong.
> In any case, the important thing is to know whether the syntax precludes the
> specification of additional parameters.
>
> > 3. I think that the editor of H.235 will look to see if the proposed AVD
> > allows to specify and change a key for each payload that can be used in
> the
> > logical channel. I am not an expert on H.235
>
> Most definitely.. I would certainly welcome comments and input in the area
> of security.
>
> Paul
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com
More information about the sg16-avd
mailing list