6f7d4accf82ed322bd4e36e509909e37c7c2a9fe
[crypto.git] / doc / draft-riikonen-silc-multimedia-session-00.nroff
1 .pl 10.0i
2 .po 0
3 .ll 7.2i
4 .lt 7.2i
5 .nr LL 7.2i
6 .nr LT 7.2i
7 .ds LF Riikonen
8 .ds RF FORMFEED[Page %]
9 .ds CF
10 .ds LH Internet-Draft
11 .ds RH 15 January 2007
12 .ds CH
13 .na
14 .hy 0
15 .in 0
16 .nf
17 Network Working Group                                        P. Riikonen
18 Internet-Draft
19 draft-riikonen-silc-multimedia-session-00.txt            15 January 2007
20 Expires: 15 July 2007
21
22 .in 3
23
24 .ce 2
25 Multimedia Sessions in SILC protocol
26 <draft-riikonen-silc-multimedia-session-00.txt>
27
28 .ti 0
29 Status of this Memo
30
31 This document is an Internet-Draft and is in full conformance with
32 all provisions of Section 10 of RFC 2026.  Internet-Drafts are
33 working documents of the Internet Engineering Task Force (IETF), its
34 areas, and its working groups.  Note that other groups may also
35 distribute working documents as Internet-Drafts.
36
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time.  It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
41
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
44
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
47
48 The distribution of this memo is unlimited.
49
50
51 .ti 0
52 Abstract
53
54 This document defines the use of multimedia protocols and the set up
55 of multimedia sessions in the Secure Internet Live Conferencing (SILC)
56 protocol [SILC1].
57
58
59 .ti 0
60 Table of Contents
61
62 .nf
63 1 Introduction ..................................................  2
64   1.1 Requirements Terminology ..................................  2
65 2 Recommended Protocol ..........................................  2
66 3 Session Description Protocol (SDP) ............................  2
67   3.1 SDP field usage in SILC ...................................  3
68   3.2 SDP Examples ..............................................  5
69 4 Session Initiation Protocol (SIP) .............................  6
70 6 Other Protocols ...............................................  6
71 7 Security Considerations .......................................  7
72 8 References ....................................................  7
73 9 Author's Address ..............................................  7
74 10 Full Copyright Statement .....................................  7
75
76
77 .ti 0
78 1 Introduction
79
80 This document defines the use of multimedia protocols and the set up
81 of multimedia sessions in the Secure Internet Live Conferencing (SILC)
82 protocol [SILC1].  The SILC protocol supports multimedia messages
83 with the Message Payload [SILC2] and SILC_MESSAGE_FLAG_DATA which
84 has the ability to define what type of content is delievered within
85 the payload.  The Message Payload is used to encapsulate the multimedia
86 session set up procedure and the actual multimedia session data.  We
87 define the recommended multimedia session protocol for SILC and also
88 consider some other protocols in the scope of SILC.
89
90
91 .ti 0
92 1.1 Requirements Terminology
93
94 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
95 MAY, and OPTIONAL, when they appear in this document, are to be
96 interpreted as described in [RFC2119].
97
98
99 .ti 0
100 2 Recommended Protocol
101
102 Since SILC protocol can encapsulate practically any protocol for setting
103 up a multimedia session we have selected the Session Description Protocol
104 (SDP) as RECOMMENDED protocol.  It was chosen for its maturity, simplicity
105 and versatility.  If multimedia features are implemented in SILC
106 application it is recommended that at least support for SDP is added.
107
108
109 .ti 0
110 3 Session Description Protocol (SDP)
111
112 The SDP [SDP] protocol defines a general purpose multimedia session
113 description protocol.  SDP is one of the simplest protocols to negotiate
114 multimedia sessions and is suited perfectly for SILC protocol.  Since SDP
115 does not itself define how it is used to set up the session, we define it
116 here for SILC.  The definition is based on the [RFC3264] and [RFC4145].
117
118 In SILC the SDP messages are sent as data messages (MIME message).  They
119 can be destined directly to a client for direct conferencing, or to a
120 channel for group conferencing.  It is also possible to send the message
121 directly to client to invite them to group conferencing before they have
122 joined the channel.  The MIME type used is application/sdp.
123
124 To set up a multimedia session a client sends SILC message with
125 SILC_MESSAGE_FLAG_DATA and SILC_MESSAGE_FLAG_REQUEST flags set and with
126 MIME SDP message in the message payload.  If the receiver wants to
127 participate in the multimedia session it sends MIME SDP message back with
128 SILC_MESSAGE_FLAG_DATA and SILC_MESSAGE_FLAG_REPLY flags set to the
129 sender.  If reply is not received after an application defined period of
130 time the message may be retransmitted or the session set up may be
131 terminated.
132
133 After reply has been received the multimedia session is started according
134 to the SDP and all multimedia data is sent using SILC data messages.  When
135 performing peer-to-peer connection the SDP defines which party initiates
136 the connection.  After initiation the SILC Key Exchange protocol MUST be
137 performed.  The resulted key material will be used to protect the multimedia
138 session.  Multimedia data transmission may start after the key exchange
139 has been performed.  When performing group conferencing all parties
140 independently connect to the SILC server specified in the SDP.  In other
141 cases when performing the multimedia session inside the SILC network, any
142 party may start transmitting the multimedia data after the SDPs have been
143 exchanged.
144
145 To terminate the session, or to reject incoming request, an MD5 digest
146 MUST be computed from the original SDP data, and the digest is sent back
147 with the SILC_MESSAGE_FLAG_DATA and SILC_MESSAGE_FLAG_STOP flags set.
148 The receiver of such message should verify the MD5 digest and terminate
149 the session if it matches any active session.  The session may also be
150 terminated by closing network connection.  In group sessions simply by
151 leaving the channel terminates the session.  The original sender of the
152 SDP message may send the terminating message to notify all clients on the
153 channel to terminate the session.  If the original sender on channel
154 receives the terminating message it takes no action on it.
155
156 .ti 0
157 3.1 SDP field usage in SILC
158
159 The Encryption Keys (k=) field describes encryption key to protect the
160 multimedia session.  As SILC protocol transport and the multimedia session
161 is secured by default this field SHOULD NOT be used.
162
163
164 The Origin (o=) field describes from where the session originates.  The
165 <username> sub-field is the sender's SILC nickname.  Examples:
166
167         o=foobar 2890844521 2890842804 IN IP4 10.2.1.7
168
169
170 The Connection Data (c=) field describes the connection information for
171 the multimedia session.  When performing peer-to-peer multimedia session
172 the <network type> is 'IN', indicating Internet connection.  When
173 performing multimedia session inside SILC network it is 'SILC'.  When the
174 'SILC' network type is used the <address type> and <connection address>
175 sub-fields are omitted.  Examples:
176
177         c=SILC
178         c=IN IP4 10.2.1.7
179
180
181 The Media Announcements (m=) field describes the media information for the
182 multimedia session.  If the network type in c= field is 'SILC' the <port>
183 sub-field MUST be set to 9 (discard).  The <transport> for RTP over UDP is
184 'RTP/AVP', for RTP over TCP it is 'TCP/RTP/AVP', and for non-RTP protocol
185 over UDP it is 'udp' and over TCP it is 'tcp'.  The <fmt> sub-field
186 includes the RTP media payload number when using RTP.  When using non-RTP
187 protocol it includes MIME subtype.  Examples:
188
189         c=SILC
190         m=audio 9 TCP/RTP/AVP 3
191         a=rtpmap:3 GSM/8000
192
193         c=SILC
194         m=audio 9 tcp mpeg
195
196
197 The Attributes (a=) field can be used to set various session and media
198 specific attributes.  For SILC we define attribute "silc".
199
200         a=silc:<session type> <parameters>
201
202 The <session type> is either "direct" or "group".  When it is "direct"
203 and the c= field defines a connection point the connection will be
204 peer-to-peer connection to the remote client.  If it is "group" and the
205 the c= field defines a connection point the connection will be to a remote
206 SILC server for group conferencing.  If c= field includes "SILC" network
207 type, then "direct" is for direct session with a client in SILC network
208 and "group" is for group conferencing in SILC network.  If the "silc"
209 attribute is omitted the session type is expected to be "direct".  The
210 following parameters are defined for attribute "silc".
211
212         channel         The name of the channel for group conferencing.
213                         Can be used only with "group" session type.
214                         More than one channel parameters may be defined.
215
216
217 The [RFC4145] specifies a "setup" attribute that defines which party of the
218 session will initiate the connection when performing peer-to-peer session.
219 Its use in SILC is as specified in [RFC4145] and MUST be present in SDP
220 when the c= field includes an actual connection point and when the "silc"
221 attribute session type is "direct", or if the attribute is not present at
222 all.  When performing group conferencing each party always need to create
223 the connection to the server and the "setup" attribute need not be present
224 in SDP.
225
226 .ti 0
227 3.2 SDP Examples
228
229         v=0
230         o=foobar 2890844521 2890842804 IN IP4 10.2.1.100
231         s=peer-to-peer example
232         t=0 0
233         m=audio 5000 TCP/RTP/AVP 3
234         c=IN IP4 10.2.1.100
235         a=rtpmap:3 GSM/8000
236         a=silc:direct
237         a=setup:active
238
239 This example sets up a peer-to-peer session to remote client at
240 10.2.1.100 at port 5000.
241
242         v=0
243         o=foobar 2890844521 2890842804 IN IP4 10.2.1.32
244         s=Group conferencing example
245         c=IN IP4 10.2.1.7
246         t=0 0
247         a=silc:group channel=foobar
248         m=audio 706 TCP/RTP/AVP 3
249         a=rtpmap:3 GSM/8000
250
251 This example sets up a session to a remote SILC server 10.2.1.7 at port
252 706.  Once connected the channel "foobar" will be joined for group
253 conferencing.
254
255         v=0
256         o=foobar 2890844521 2890842804 IN IP4 10.2.1.32
257         s=SILC network chat example
258         c=SILC
259         t=0 0
260         m=audio 9 TCP/RTP/AVP 3
261         a=rtpmap:3 GSM/8000
262
263 This example sets up a session inside SILC network with the remote user
264 "foobar".
265
266         v=0
267         o=foobar 2890844521 2890842804 IN IP4 10.2.1.32
268         s=SILC network group conferencing example
269         t=0 0
270         m=audio 9 TCP/RTP/AVP 3
271         c=SILC
272         a=rtpmap:3 GSM/8000
273         a=silc:group channel=group-chat
274
275 This example sets up a group conferencing session inside SILC network on
276 channel "group-chat".
277
278
279 .ti 0
280 4 Session Initiation Protocol (SIP)
281
282 The SIP [SIP] protocol is a general purpose protocol for setting up,
283 modifying and terminating different kinds of sessions, including
284 multimedia sessions.  The SIP protocol use the SDP to describe the
285 multimedia session.
286
287 In SILC the SIP messages are sent as data messages (MIME message).  They
288 can be destined directly to a client for direct conferencing, or to a
289 channel for group conferencing.  It is also possible to send the message
290 directly to client to invite them to group conferencing before they have
291 joined the channel.  The MIME type used is application/sip.  The
292 SILC_MESSAGE_FLAG_DATA flag must be set in each message and the message
293 payload includes a MIME SIP message.  The actual SIP session set up and
294 termination is described in the SIP protocol specification, and SILC
295 protocol merely provides a secure transport for the session.  After the
296 session is set up all multimedia data is sent using SILC data messages.
297 The MIME type for the multimedia data messages is defined during the SIP
298 session set up.
299
300 The rules for SDP fields described in previous section also applies for
301 SDP with SIP in the context of SILC.
302
303 Proxy and redirection servers usually would not be used in the context of
304 SILC, unless the sessions are redirected to outside SILC network.  This
305 may compromise the security of the session.
306
307 The S/MIME need not be used when using SIP in SILC protocol.  The SILC
308 protocol transport and the created multimedia session is secured by
309 default.
310
311
312 .ti 0
313 6 Other Protocols
314
315 There are other open and proprietary protocols for setting up multimedia
316 sessions.  One important is H.323 using the H.225 to set up the session.
317 This document should later define the use of H.323 with SILC.
318 Practically any protocol to set up multimedia sessions may be used with
319 SILC by using SILC as a secure transport to set up the session, and to use
320 SILC data messages (MIME messages) to secure and deliver the actual
321 multimedia data once the session has been established.
322
323
324 .ti 0
325 7 Security Considerations
326
327 Security is central to the design of this protocol, and these security
328 considerations permeate the specification.  Common security considerations
329 such as keeping private keys truly private and using adequate lengths for
330 symmetric and asymmetric keys must be followed in order to maintain the
331 security of this protocol.
332
333
334 .ti 0
335 8 References
336
337 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
338              Protocol Specification", Internet Draft, June 2003.
339
340 [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
341              June 2003.
342
343 [RFC3264]    Rosenberg, J., et. al., "An Offer/Answer Model with the
344              Session Description Protocol (SDP)", RFC 3264, June 2002.
345
346 [RFC4145]    Yon, D., et. al., "TCP-Based Media Transport in the
347              Session Description Protocol (SDP)", RFC 4145, September
348              2005.
349
350 [SIP]        Rosenberg, J., et. al., "SIP: Session Initiation Protocol",
351              RFC 3261, June 2002.
352
353
354
355 .ti 0
356 9 Author's Address
357
358 .nf
359 Pekka Riikonen
360 Helsinki
361 Finland
362
363 EMail: priikone@iki.fi
364
365
366 .ti 0
367 10 Full Copyright Statement
368
369 Copyright (C) The Internet Society (2003). All Rights Reserved.
370
371 This document and translations of it may be copied and furnished to
372 others, and derivative works that comment on or otherwise explain it
373 or assist in its implementation may be prepared, copied, published
374 and distributed, in whole or in part, without restriction of any
375 kind, provided that the above copyright notice and this paragraph are
376 included on all such copies and derivative works. However, this
377 document itself may not be modified in any way, such as by removing
378 the copyright notice or references to the Internet Society or other
379 Internet organizations, except as needed for the purpose of
380 developing Internet standards in which case the procedures for
381 copyrights defined in the Internet Standards process must be
382 followed, or as required to translate it into languages other than
383 English.
384
385 The limited permissions granted above are perpetual and will not be
386 revoked by the Internet Society or its successors or assigns.
387
388 This document and the information contained herein is provided on an
389 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
390 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
391 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
392 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
393 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.