The SILC Project

source navigation ]
identifier search ]
freetext search ]
file search ]

silc/doc/draft-riikonen-silc-pp-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 13 September 2000
 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-pp-00.txt                        13 September 2000
 20 Expires: 13 May 2001
 21 
 22 .in 3
 23 
 24 .ce 2
 25 SILC Packet Protocol
 26 <draft-riikonen-silc-pp-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 memo describes a Packet Protocol used in the Secure Internet Live
 55 Conferencing (SILC) protocol specified in the Secure Internet Live
 56 Conferencing, Protocol Specification Internet Draft [SILC1].  This
 57 protocol describes the packet types and packet payloads which defines
 58 the contents of the packets.  The protocol provides secure binary packet
 59 protocol that assures that the contents of the packets are secured and
 60 authenticated.
 61 
 62 
 63 
 64 
 65 
 66 
 67 
 68 
 69 
 70 .ti 0
 71 Table of Contents
 72 
 73 .nf
 74 1 Introduction ..................................................  3
 75 2 SILC Packet Protocol ..........................................  4
 76   2.1 SILC Packet ...............................................  4
 77   2.2 SILC Packet Header ........................................  5
 78   2.3 SILC Packet Types .........................................  7
 79       2.3.1 SILC Packet Payloads ................................ 15
 80       2.3.2 Disconnect Payload .................................. 15
 81       2.3.3 Success Payload ..................................... 16
 82       2.3.4 Failure Payload ..................................... 16
 83       2.3.5 Reject Payload ...................................... 17
 84       2.3.6 Notify Payload ...................................... 17
 85       2.3.7 Error Payload ....................................... 18
 86       2.3.8 Channel Message Payload ............................. 19
 87       2.3.9 Channel Key Payload ................................. 20
 88       2.3.10 Private Message Payload ............................ 23
 89       2.3.11 Private Message Key Payload ........................ 24
 90       2.3.12 Command Payload .................................... 25
 91              2.3.12.1 Command Argument Payload .................. 25
 92       2.3.13 Command Reply Payload .............................. 26
 93       2.3.14 Connection Auth Request Payload .................... 27
 94       2.3.15 New ID Payload ..................................... 28
 95       2.3.16 New ID List Payload ................................ 29
 96       2.3.17 New Client Payload ................................. 29
 97       2.3.18 New Server Payload ................................. 31
 98       2.3.19 New Channel Payload ................................ 31
 99       2.3.20 New Channel User Payload ........................... 32
100       2.3.21 New Channel List Payload ........................... 33
101       2.3.22 New Channel User List Payload ...................... 34
102       2.3.23 Replace ID Payload ................................. 34
103       2.3.24 Remove ID Payload .................................. 35
104   2.4 SILC ID Types ............................................. 36
105   2.5 Packet Encryption And Decryption .......................... 37
106       2.5.1 Normal Packet Encryption And Decryption ............. 37
107       2.5.2 Channel Message Encryption And Decryption ........... 37
108       2.5.3 Private Message Encryption And Decryption ........... 38
109   2.6 Packet MAC Generation ..................................... 39
110   2.7 Packet Padding Generation ................................. 39
111   2.8 Packet Compression ........................................ 40
112   2.9 Packet Sending ............................................ 40
113   2.10 Packet Reception ......................................... 41
114   2.11 Packet Routing ........................................... 42
115   2.12 Packet Forwarding ........................................
116   2.13 Packet Broadcasting ...................................... 41
117   2.14 Packet Tunneling ......................................... 42
118 3 Security Considerations ....................................... 43
119 4 References .................................................... 43
120 5 Author's Address .............................................. 44
121 
122 .ti 0
123 List of Figures
124 
125 .nf
126 Figure 1:   Typical SILC Packet
127 Figure 2:   SILC Packet Header
128 Figure 3:   Disconnect Payload
129 Figure 4:   Success Payload
130 Figure 5:   Failure Payload
131 Figure 6:   Reject Payload
132 Figure 7:   Notify Payload
133 Figure 8:   Error Payload
134 Figure 9:   Channel Message Payload
135 Figure 10:  Channel Key Payload
136 Figure 11:  Private Message Payload
137 Figure 12:  Private Message Key Payload
138 Figure 13:  Command Payload
139 Figure 14:  Command Argument Payload
140 Figure 15:  Connection Auth Request Payload
141 Figure 16:  New ID Payload
142 Figure 17:  New Client Payload
143 Figure 18:  New Server Payload
144 Figure 19:  New Channel Payload
145 Figure 20:  New Channel User Payload
146 Figure 21:  Replace ID Payload
147 Figure 22:  Remove ID Payload
148 Figure 23:  Remove Channel User Payload
149 
150 
151 .ti 0
152 1. Introduction
153 
154 This document describes a Packet Protocol used in the Secure Internet
155 Live Conferencing (SILC) protocol specified in the Secure Internet Live
156 Conferencing, Protocol Specification Internet Draft [SILC1].  This
157 protocol describes the packet types and packet payloads which defines
158 the contents of the packets.  The protocol provides secure binary packet
159 protocol that assures that the contents of the packets are secured and
160 authenticated.
161 
162 The basis of SILC protocol relies in the SILC packets and it is with
163 out a doubt the most important part of the protocol.  It is also probably
164 the most complicated part of the protocol.  Packets are used all the
165 time in the SILC network to send messages, commands and other information.
166 All packets in SILC network are always encrypted and their integrity
167 is assured by computed MACs.  The protocol defines several packet types
168 and packet payloads.  Each packet type usually has a specific packet
169 payload that actually defines the contents of the packet.  Each packet
170 also includes a default SILC Packet Header that provides sufficient
171 information about the origin of the packet and destination of the
172 packet.
173 
174 
175 .ti 0
176 2 SILC Packet Protocol
177 
178 .ti 0
179 2.1 SILC Packet
180 
181 SILC packets deliver messages from sender to receiver securely by
182 encrypting important fields of the packet.  The packet consists of
183 default SILC Packet Header, Padding, Packet Payload data, and, packet 
184 MAC.
185 
186 The following diagram illustrates typical SILC packet.
187 
188 
189 .in 5
190 .nf
191  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
192 |   n bytes   | 1 - n bytes |      n bytes       |  n bytes       
193 | SILC Header |   Padding   |    Data Payload    |    MAC    
194  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
195 .in 3
196 
197 .ce
198 Figure 1:  Typical SILC Packet
199 
200 
201 SILC Header is always the first part of the packet and its purpose
202 is to provide information about the packet.  It provides for example
203 the packet type, origin of the packet and the destination of the packet.
204 The header is variable in length and first two (2) bytes of the
205 header (thus first two bytes of the packet) are not encrypted.  The
206 first two (2) bytes are the length of the packet which is not encrypted.
207 See following section for description of SILC Packet header.  Packets
208 without SILC header or with malformed SILC header must be dropped.
209 
210 Padding follows the packet header.  The purpose of the padding is to
211 make the packet multiple by eight (8) or by the block size of the
212 cipher used in the encryption, which ever is larger.  The maximum
213 length of padding is currently 16 bytes.  The padding is always
214 encrypted.
215 
216 Data payload area follows padding and it is the actual data of the
217 packet.  The packet data is the packet payloads defined in this
218 protocol.  The data payload area is always encrypted.
219 
220 The last part of SILC packet is the packet MAC that assures the
221 integrity of the packet.  The MAC is always computed from the packet
222 before the encryption is applied to the packet.  If compression is used
223 in the packet the MAC is computed after the compression has been
224 applied.  The compression, on the other hand, is always applied before
225 encryption.
226 
227 All fields in all packet payloads are always in MSB (most significant
228 byte first) order.
229 
230 
231 .ti 0
232 2.2 SILC Packet Header
233 
234 The default SILC packet header is applied to all SILC packets and it is
235 variable in length.  The purpose of SILC Packet header is to provide
236 detailed information about the packet.  The receiver of the packet uses
237 the packet header to parse the packet and gain other relevant parameters
238 of the packet.
239 
240 Following diagram represents the default SILC header format.
241 (*) indicates that this field is never encrypted.  Other fields are
242 always encrypted.
243 
244 
245 .in 5
246 .nf
247                       1                   2                   3
248  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
250 |        Payload Length *       |     Flags     |  Packet Type  |
251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
252 |        Source ID Length       |     Destination ID Length     |
253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
254 |  Src ID Type  |                                               |
255 +-+-+-+-+-+-+-+-+                                               +
256 |                                                               |
257 ~                           Source ID                           ~
258 |                                                               |
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 |  Dst ID Type  |                                               |
261 +-+-+-+-+-+-+-+-+                                               +
262 |                                                               |
263 ~                         Destination ID                        ~
264 |                                                               |
265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
266 .in 3
267 
268 .ce
269 Figure 2:  SILC Packet Header
270 
271 
272 .in 6
273 o Payload Length (2 bytes) - Is the length of the packet
274   not including the padding of the packet.  This field must
275   not be encrypted but must always be authenticated.
276 
277 o Flags (1 byte) - Indicates flags to be used in packet
278   processing.  Several flags may be set by ORing the flags
279   together.
280 
281   Following flags are reserved for this field:
282 
283 
284 
285 
286      No flags                  0x00
287 
288        In this case the field is ignored.
289 
290 
291      Private Message Key       0x01
292 
293        Indicates that the packet must include private
294        message that is encrypted using private key set by
295        client.  Servers does not know anything about this
296        key and this causes that the private message is
297        not handled by the server at all, it is just
298        passed along.  See section 2.5.3 Private Message
299        Encryption And Decryption for more information.
300 
301 
302      Forwarded                 0x02
303   
304        Marks the packet to be forwarded.  Some specific
305        packet types may be forwarded.  Receiver of packet
306        with this flag set must not forward the packet any
307        further.  See section 2.12 Packet Forwarding for
308        desribtion of packet forwarding.
309 
310 
311      Broadcast                 0x04
312 
313        Marks the packet to be broadcasted.  Client cannot
314        send broadcast packet and normal server cannot send
315        broadcast packet.  Only router server may send broadcast
316        packet.  The router receiving of packet with this flag 
317        set must send (broadcast) the packet to its primary
318        route.  If router has several router connections the
319        packet may be sent only to the primary route.  See
320        section 2.13 Packet Broadcasting for description of 
321        packet broadcasting.
322 
323 
324      Tunneled                  0x08
325 
326        Marks that the packet is tunneled.  Tunneling means
327        that extra SILC Packet Header has been applied to the
328        original packet.  The outer header has this flag
329        set.  See section 2.14 Packet Tunneling for more
330        information.
331 .in 3
332 
333 
334 
335 o Packet Type (1 byte) - Is the type of the packet. Receiver 
336   uses this field to parse the packet.  See section 2.3
337   SILC Packets for list of defined packet types.
338 
339 o Source ID Length (2 bytes) - Indicates the length of the
340   Source ID field in the header, not including this or any
341   other fields.
342 
343 
344 
345 o Destination ID Length (2 bytes) - Indicates the length of the
346   Destination ID field in the header, not including this or
347   any other fields.
348 
349 o Src ID Type (1 byte) - Indicates the type of ID in the
350   Source ID field.  See section 2.4 SILC ID Types for
351   defined ID types.
352 
353 o Source ID (variable length) - The actual source ID that
354   indicates who is the original sender of the packet.
355 
356 o Dst ID Type (1 byte) - Indicates the type of ID in the
357   Destination ID field.  See section 2.4 SILC ID Types for
358   defined ID types.
359 
360 o Destination ID (variable length) - The actual source ID that
361   indicates who is the end receiver of the packet.
362 
363 
364 .ti 0
365 2.3 SILC Packet Types
366 
367 SILC packet types defines the contents of the packet and it is used by
368 the receiver to parse the packet.  The packet type is 8 bits, as a one
369 byte, in length.  The range for the packet types are from 0 - 255,
370 where 0 is never sent and 255 is currently reserved for future
371 extensions and must not be defined to any other purpose.  Every SILC
372 specification compliant implementation should support all of these packet
373 types.
374 
375 The below list of the SILC Packet types includes reference to the packet
376 payload as well.  Packet payloads are the actual packet, that is, the data
377 that the packet consists of.  Each packet type defines packet payload 
378 which usually may only be sent with the specific packet type.
379 
380 Most of the packets are packets that must be destined directly to entity
381 that is connected to the sender.  It is not allowed, for example, for
382 router to send disconnect packet to client that is not directly connected
383 to the router.  However, there are some special packet types that may
384 be destined to some entity that the sender has not direct connection
385 with.  These packets are for example private message packets, channel
386 message packets, command packets and some other packets that may be
387 broadcasted in the SILC network.  If the packet is allowed to be sent to
388 indirectly connected entity it is mentioned separately in the packet
389 description (unless it is obvious as in private and channel message
390 packets).  Other packets must not be sent or accepted, if sent, to
391 indirectly connected entities.
392 
393 List of SILC Packet types are defined as follows.
394 
395 .in 1
396      0    SILC_PACKET_NONE
397 
398           This type is reserved and it is never sent.         
399 
400 
401      1    SILC_PACKET_DISCONNECT
402 
403           This packet is sent to disconnect the remote end.  Reason of
404           the disconnection is sent inside the packet payload.  Client
405           usually does not send this packet.
406 
407           Payload of the packet:  See section 2.3.2 Disconnect Payload
408 
409 
410      2    SILC_PACKET_SUCCESS
411 
412           This packet is sent upon successful execution of some protocol.
413           The status of the success is sent in the packet.
414 
415           Payload of the packet:  See section 2.3.3 Success Payload
416 
417 
418      3    SILC_PACKET_FAILURE
419 
420           This packet is sent upon failure of some protocol.  The status
421           of the failure is sent in the packet.
422 
423           Payload of the packet:  See section 2.3.4 Failure Payload
424 
425 
426      4    SILC_PACKET_REJECT
427 
428           This packet may be sent upon rejection of some protocol.
429           The status of the rejection is sent in the packet.
430 
431           Payload of the packet:  See section 2.3.5 Reject Payload
432 
433 
434      5    SILC_PACKET_NOTIFY
435 
436           This packet is used to send notify message, usually from
437           server to client, although it may be sent from server to another
438           server as well.  Client never sends this packet.  Server may
439           send this packet to channel as well when the packet is 
440           distributed to all clients on the channel.  Receiver of this 
441           packet may ignore the packet if it chooses so.  However, it 
442           should not be ignored.
443 
444           Payload of the packet:  See section 2.3.6 Notify Payload.
445 
446 
447      6    SILC_PACKET_ERROR
448 
449           This packet is sent when an error occurs.  Server may
450           send this packet.  Client never sends this packet.  The
451           client may entirely ignore the packet, however, server is
452           most likely to take action anyway.  This packet may be sent
453           to entity that is indirectly connected to the sender.
454 
455           Payload of the packet:  See section 2.3.7 Error Payload.
456 
457 
458      7    SILC_PACKET_CHANNEL_MESSAGE
459 
460           This packet is used to send messages to channels.  The packet
461           includes Channel ID of the channel and the actual message to
462           the channel.  Messages sent to the channel are always protected
463           by channel specific keys.  Channel Keys are distributed by
464           SILC_PACKET_CHANNEL_KEY packet.
465 
466           When client sends this packet the destination ID in the SILC 
467           header must be the Channel ID of the channel the message is 
468           destined to.  If server sends this packet to a client the 
469           destination ID in the SILC header must be the Client ID of 
470           the client receiving the packet.
471 
472           If server sends this packet to router or if router sends this
473           packet to server or another router the destination ID in the
474           SILC header must be the Channel ID of the channel.  Server
475           (including router) distributes this packet only to its local
476           clients who are joined to the channel.  Servers and routers
477           also determines who are on the channel and when this packet
478           needs to be sent, as described in section Client To Client
479           in [SILC1].
480 
481           Payload of the packet:  See section 2.3.8 Channel Message 
482                                   Payload
483 
484 
485      8    SILC_PACKET_CHANNEL_KEY
486 
487           This packet is used to distribute new key for particular
488           channel.  Each channel has their own independent keys that
489           is used to protect the traffic on the channel.  Only server
490           may send this packet.  This packet may be sent to entity
491           that is indirectly connected to the sender.
492 
493           Payload of the packet:  See section 2.3.9 Channel Key Payload
494 
495 
496      9    SILC_PACKET_PRIVATE_MESSAGE
497 
498           This packet is used to send private messages from client
499           to another client.  By default, private messages are protected
500           by session keys established by normal key exchange protocol.
501           However, it is possible to use specific key to protect private
502           messages.  SILC_PACKET_PRIVATE_MESSAGE_KEY packet is used to 
503           agree the key with the remote client.  Pre-shared key may be 
504           used as well if both of the client knows it, however, it needs 
505           to be agreed outside SILC.  See more of this in [SILC1].
506 
507           Payload of the packet:  See section 2.3.10 Private Message
508                                   Payload
509 
510 
511      10   SILC_PACKET_PRIVATE_MESSAGE_KEY
512 
513           This packet is used to agree about a key to be used to protect
514           the private messages between two clients.  If this is not sent
515           the normal session key is used to protect the private messages
516           inside SILC network.  Agreeing to use specific key to protect
517           private messages adds security, as no server between the two
518           clients will be able to decrypt the private message.  However,
519           servers inside SILC network are considered to be trusted, thus
520           using normal session key to protect private messages does not
521           degree security.  Whether to agree to use specific keys by
522           default or to use normal session keys by default, is 
523           implementation specific issue.  See more of this in [SILC1].
524 
525           Payload of the packet:  See section 2.3.11 Private Message
526                                   Key Payload
527 
528 
529      11   SILC_PACKET_COMMAND
530 
531           This packet is used to send commands from client to server.
532           Server may send this packet to other servers as well.  All
533           commands are listed in their own section SILC Command Types
534           in [SILC1].  The contents of this packet is command specific.
535           This packet may be sent to entity that is indirectly connected
536           to the sender.
537 
538           Payload of the packet:  See section 2.3.12 Command Payload
539 
540 
541      12   SILC_PACKET_COMMAND_REPLY
542 
543           This packet is send as reply to the SILC_PACKET_COMMAND packet.
544           The contents of this packet is command specific.  This packet
545           maybe sent to entity that is indirectly connected to the sender.
546 
547           Payload of the packet:  See section 2.3.13 Command Reply 
548                                   Payload and section 2.3.12 Command
549                                   Payload
550 
551 
552      13   SILC_PACKET_KEY_EXCHANGE
553 
554           This packet is used to start SILC Key Exchange Protocol, 
555           described in detail in [SILC3].
556 
557           Payload of the packet:  Payload of this packet is described
558                                   in the section SILC Key Exchange
559                                   Protocol and its sub sections in
560                                   [SILC3].
561 
562 
563      14   SILC_PACKET_KEY_EXCHANGE_1
564 
565           This packet is used as part of the SILC Key Exchange Protocol.
566 
567           Payload of the packet:  Payload of this packet is described
568                                   in the section SILC Key Exchange
569                                   Protocol and its sub sections in
570                                   [SILC3].
571 
572 
573      15   SILC_PACKET_KEY_EXCHANGE_2
574 
575           This packet is used as part of the SILC Key Exchange Protocol.
576 
577           Payload of the packet:  Payload of this packet is described
578                                   in the section SILC Key Exchange
579                                   Protocol and its sub sections in
580                                   [SILC3].
581 
582 
583      16   SILC_PACKET_CONNECTION_AUTH_REQUEST
584 
585           This packet is used to request the authentication method to
586           be used in the SILC Connection Authentication Protocol.  If 
587           initiator of the protocol does not know the mandatory 
588           authentication method this packet is used to determine it.
589 
590           The party receiving this payload must respond with the same
591           packet including the mandatory authentication method.
592 
593           Payload of the packet:  See section 2.3.14 Connection Auth
594                                   Request Payload
595 
596 
597      17   SILC_PACKET_CONNECTION_AUTH
598 
599           This packet is used to start and perform the SILC Connection
600           Authentication Protocol.  This protocol is used to authenticate
601           the connecting party.  The protocol is described in detail in
602           [SILC3].
603 
604           Payload of the packet:  Payload of this packet is described
605                                   in the section SILC Authentication
606                                   Protocol and it sub sections in [SILC].
607 
608 
609      18   SILC_PACKET_NEW_ID
610 
611           This packet is used to distribute new ID's from server to
612           router and from router to all routers in the SILC network.
613           This is used when for example new client is registered to
614           SILC network.  The newly created ID's of these operations are
615           distributed by this packet.  Only server may send this packet,
616           however, client must be able to receive this packet.
617 
618           Payload of the packet:  See section 2.3.15 New ID Payload
619 
620 
621      19   SILC_PACKET_NEW_ID_LIST
622 
623           This packet is used to distribute list of new ID's from
624           server to routers.  This is equivalent to previous packet
625           type except that it may include several ID's.  Client must
626           not send this packet.
627 
628           Payload of the packet:  See section 2.3.16 New ID List 
629                                   Payload
630 
631 
632      20   SILC_PACKET_NEW_CLIENT
633 
634           This packet is used by client to register itself to the
635           SILC network.  This is sent after key exchange and 
636           authentication protocols has been completed.  Client sends
637           various information about itself in this packet.
638 
639           Payload of the packet:  See section 2.3.17 New Client Payload
640 
641 
642      21   SILC_PACKET_NEW_SERVER
643 
644           This packet is used by server to register itself to the
645           SILC network.  This is sent after key exchange and 
646           authentication protocols has been completed.  Server sends
647           this to the router it connected to, or, if router was
648           connecting, to the connected router.  Server sends
649           its Server ID and other information in this packet.
650           Client must not send or receive this packet.
651 
652           Payload of the packet:  See section 2.3.18 New Server Payload
653 
654 
655      22   SILC_PACKET_NEW_CHANNEL
656 
657           This packet is used to notify routers about newly created
658           channel.  Channels are always created by the router and it must
659           notify other routers about the created channel.  Router sends
660           this packet to its primary route.  Client must not send this
661           packet.  This packet maybe sent to entity that is indirectly
662           connected to the sender.
663 
664           Payload of the packet:  See section 2.3.19 New Channel Payload
665 
666 
667      23   SILC_PACKET_NEW_CHANNEL_USER
668 
669           This packet is used to notify routers about new user on channel.
670           The packet is sent after user has joined to the channel.  Server
671           may send this packet to its router and router may send this to
672           its primary router.  Client must not send this packet.  This
673           packet maybe sent to entity that is indirectly connected to the
674           sender.
675 
676           Payload of the packet:  See section 2.3.20 New Channel User
677                                   Payload
678 
679 
680      24   SILC_PACKET_NEW_CHANNEL_LIST
681 
682           This packet is used to distribute list of created channels
683           from server to routers.  This is equivalent to the packet
684           SILC_PACKET_NEW_CHANNEL except that it may include several
685           payloads. Client must not send this packet.
686 
687           Payload of the packet:  See section 2.3.21 New Channel List
688                                   Payload
689 
690 
691      25   SILC_PACKET_NEW_CHANNEL_USER_LIST
692 
693           This packet is used to distribute list of users on specific
694           channel from server to routers.  This is equivalent to the
695           packet SILC_PACKET_NEW_CHANNEL_USER except that it may
696           include several payloads.  Client must not send this packet.
697 
698           Payload of the packet:  See section 2.3.22 New Channel User
699                                   List Payload
700 
701 
702      26   SILC_PACKET_REPLACE_ID
703 
704           This packet is used to replace old ID with new ID sent in
705           the packet payload.  For example, when client changes its
706           nickname new ID is created and this packet can be used to
707           distribute the new ID and the old ID is removed when it is
708           send in the packet.  Client cannot send or receive this
709           packet.  This packet maybe sent to entity that is indirectly
710           connected to the sender.
711 
712           Payload of the packet:  See section 2.3.23 Replace ID Payload
713 
714 
715      27   SILC_PACKET_REMOVE_ID
716 
717           This packet is used to removed ID.  For example, when client
718           exits SILC network its ID is removed.  Client must not send
719           this packet.  This packet maybe sent to entity that is
720           indirectly connected to the sender.
721 
722           Payload of the packet:  See section 2.3.24 Remove ID Payload
723 
724 
725      28   SILC_PACKET_REMOVE_CHANNEL_USER
726 
727           This packet is used to remove user from a channel.  This is
728           used by router to notify other routers in the network that a
729           client has leaved a channel.  This packet maybe sent to entity
730           that is indirectly connected to the sender.
731 
732           Payload of the packet:  See section 2.3.25 Remove Channel User
733                                   Payload
734 
735 
736      29   SILC_PACKET_REKEY
737 
738           This packet is used to indicate that re-key must be performed
739           for session keys.  See section Session Key Regeneration in
740           [SILC1] for more information.  This packet does not have
741           a payload.
742 
743 
744      30   SILC_PACKET_REKEY_DONE
745 
746           This packet is used to indicate that re-key is performed and
747           new keys must be used hereafter.  This is sent only if re-key
748           was done without PFS option.  If PFS is set, this is not sent
749           as SILC Key Exchange protocol is executed.  This packet does
750           not have a payload.
751 
752 
753      31 - 254
754 
755          Currently undefined commands.
756 
757 
758      255 SILC_PACKET_MAX
759 
760          This type is reserved for future extensions and currently it 
761          is not sent.
762 .in 3
763 
764 
765 .ti 0
766 2.3.1 SILC Packet Payloads
767 
768 All payloads resides in the main data area of the SILC packet.  However
769 all payloads must be at the start of the data area after the default
770 SILC packet header and padding.  All fields in the packet payload are
771 always encrypted, as, they reside in the data area of the packet which
772 is always encrypted.
773 
774 Payloads described in this section are common payloads that must be
775 accepted anytime during SILC session.  Most of the payloads may only
776 be sent with specific packet type which is defined in the description
777 of the payload.
778 
779 There are a lot of other payloads in the SILC as well.  However, they
780 are not common in the sense that they could be sent at any time. 
781 These payloads are not described in this section.  These are payloads
782 such as SILC Key Exchange payloads and so on.  These are described
783 in [SILC1] and [SILC3].
784 
785 
786 .ti 0
787 2.3.2 Disconnect Payload
788 
789 Disconnect payload is sent upon disconnection.  The payload is simple;
790 reason of disconnection is sent to the disconnected party.
791 
792 The payload may only be sent with SILC_PACKET_DISCONNECT packet.  It
793 must not be sent in any other packet type.  Following diagram represents
794 the Disconnect Payload.
795 
796 
797 .in 5
798 .nf
799                      1                   2                   3
800  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 |                                                               |
803 ~                      Disconnect Message                       ~
804 |                                                               |
805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
806 .in 3
807 
808 .ce
809 Figure 3:  Disconnect Payload
810 
811 
812 
813 
814 .in 6
815 o Disconnect Message (variable length) - Human readable
816   reason of the disconnection.
817 .in 3
818 
819 
820 .ti 0
821 2.3.3 Success Payload
822 
823 Success payload is sent when some protocol execution is successfully
824 completed.  The payload is simple; indication of the success is sent.
825 This maybe any data, including binary or human readable data.
826 
827 .in 5
828 .nf
829                      1                   2                   3
830  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
832 |                                                               |
833 ~                      Success Indication                       ~
834 |                                                               |
835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
836 .in 3
837 
838 .ce
839 Figure 4:  Success Payload
840 
841 
842 .in 6
843 o Success Indication (variable length) - Indication of
844   the success.  This maybe for example some flag that
845   indicates the protocol and the success status or human
846   readable success message.  The true length of this
847   payload is available by calculating it from the SILC
848   Packet Header.
849 .in 3
850 
851 
852 .ti 0
853 2.3.4 Failure Payload
854 
855 This is opposite of Success Payload.  Indication of failure of
856 some protocol is sent in the payload.
857 
858 
859 .in 5
860 .nf
861                      1                   2                   3
862  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
864 |                                                               |
865 ~                      Failure Indication                       ~
866 |                                                               |
867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
868 .in 3
869 
870 .ce
871 Figure 5:  Failure Payload
872 
873 
874 .in 6
875 o Failure Indication (variable length) - Indication of
876   the failure.  This maybe for example some flag that
877   indicates the protocol and the failure status or human
878   readable failure message.  The true length of this
879   payload is available by calculating it from the SILC
880   Packet Header.
881 .in 3
882 
883 
884 .ti 0
885 2.3.5 Reject Payload
886 
887 This payload is sent when some protocol is rejected to be executed.
888 Other operations may send this as well that was rejected.  The
889 indication of the rejection is sent in the payload.  The indication
890 may be binary or human readable data.
891 
892 
893 .in 5
894 .nf
895                      1                   2                   3
896  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
898 |                                                               |
899 ~                       Reject Indication                       ~
900 |                                                               |
901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
902 .in 3
903 
904 .ce
905 Figure 6:  Reject Payload
906 
907 
908 .in 6
909 o Reject Indication (variable length) - Indication of
910   the rejection.  This maybe for example some flag that
911   indicates the protocol and the rejection status or human
912   readable rejection message.  The true length of this
913   payload is available by calculating it from the SILC
914   Packet Header.
915 .in 3
916 
917 
918 
919 
920 
921 .ti 0
922 2.3.6 Notify Payload
923 
924 Notify payload is used to send notify messages.  The payload is usually
925 sent from server to client, however, server may send it to another
926 server as well.  Client must not send this payload.  The receiver of
927 this payload may totally ignore the contents of the payload, however,
928 notify message should be noted and possibly logged.
929 
930 The payload may only be sent with SILC_PACKET_NOTIFY packet.  It must
931 not be sent in any other packet type.  Following diagram represents the
932 Notify Payload.
933 
934 .in 5
935 .nf
936                      1                   2                   3
937  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
939 |          Notify Type          |                               |
940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
941 |                                                               |
942 ~                        Notify Message                         ~
943 |                                                               |
944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
945 .in 3
946 
947 .ce
948 Figure 7:  Notify Payload
949 
950 
951 .in 6
952 o Notify Type (2 bytes) - Indicates the type of the notify
953   message.
954 
955 o Notify Message (variable length) - Human readable notify
956   message.
957 .in 3
958 
959 
960 .ti 0
961 2.3.7 Error Payload
962 
963 Error payload is sent upon error.  Error may occur in various
964 conditions when server sends this packet.  Client may not send this
965 payload but must be able to accept it.  However, client may
966 totally ignore the contents of the packet as server is going to
967 take action on the error anyway.  However, it is recommended
968 that the client takes error packet seriously.
969 
970 
971 .in 5
972 .nf
973                      1                   2                   3
974  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
976 |                                                               |
977 ~                         Error Message                         ~
978 |                                                               |
979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
980 .in 3
981 
982 .ce
983 Figure 8:  Error Payload
984 
985 
986 .in 6
987 o Error Message (variable length) - Human readable error
988   message.
989 .in 3
990 
991 
992 .ti 0
993 2.3.8 Channel Message Payload
994 
995 Channel messages are the most common messages sent in the SILC.
996 Channel Message Payload is used to send message to channels.  These
997 messages can only be sent if client has joined to some channel.
998 Even though this packet is the most common in SILC it is still
999 special packet.  Some special handling on sending and reception
1000 of channel message is required.
1001 
1002 Padding must be applied into this payload since the payload is
1003 encrypted separately from other parts of the packet with the
1004 channel specific key.  Hence the requirement of the padding.  
1005 The padding should be random data.  The packet must be made
1006 multiple by eight (8) or by the block size of the cipher, which
1007 ever is larger.
1008 
1009 The SILC header in this packet is encrypted with the session key
1010 of the next receiver of the packet.  Nothing else is encrypted
1011 with that key.  Thus, the actual packet and padding to be
1012 encrypted with the session key is SILC Header plus padding to it
1013 to make it multiple by eight (8) or multiple by the block size
1014 of the cipher, which ever is larger.
1015 
1016 Receiver of the the channel message packet is able to determine
1017 the channel the message is destined to by checking the destination
1018 ID from the SILC Packet header which tells the destination channel.
1019 The original sender of the packet is also determined by checking
1020 the source ID from the header which tells the client who sent
1021 the message.
1022 
1023 The payload may only be sent with SILC_PACKET_CHANNEL_MESSAGE packet.
1024 It  must not be sent in any other packet type.  Following diagram 
1025 represents the Channel Message Payload.
1026 
1027 (*) indicates that the field is not encrypted.
1028 
1029 
1030 
1031 
1032 
1033 
1034 
1035 
1036 
1037 
1038 
1039 
1040 
1041 
1042 
1043 
1044 
1045 
1046 
1047 
1048 
1049 
1050 .in 5
1051 .nf
1052                      1                   2                   3
1053  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1055 |        Nickname Length        |                               |
1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
1057 |                                                               |
1058 ~                           Nickname                            ~
1059 |                                                               |
1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1061 |         Message Length        |                               |
1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
1063 |                                                               |
1064 ~                         Message Data                          ~
1065 |                                                               |
1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1067 |        Padding Length         |                               |
1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
1069 |                                                               |
1070 ~                            Padding                            ~
1071 |                                                               |
1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1073 |                                                               |
1074 ~                       Initial Vector *                        ~
1075 |                                                               |
1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1077 .in 3
1078 
1079 .ce
1080 Figure 9:  Channel Message Payload
1081 
1082 
1083 .in 6
1084 o Nickname Length (2 bytes) - Indicates the length of the
1085   Nickname field, not including any other field.
1086 
1087 o Nickname (variable length) - Nickname of the sender of the 
1088   channel message.  This should not be trusted as a definite 
1089   sender of the channel message.  The SILC Packet Header in 
1090   the packet indicates the true sender of the packet and 
1091   client should verify that the nickname sent here belongs 
1092   to the Client ID in the SILC Packet Header.  This nickname 
1093   is merely provided to be displayed by the client.
1094 
1095   If server is sending this packet this field is not included
1096   and zero (0) length must be set to the Nickname Length field.
1097 
1098 o Message Length (2 bytes) - Indicates the length of the
1099   the Message Data field in the payload, not including any 
1100   other field.
1101 
1102 
1103 o Message Data (variable length) - The actual message to
1104   the channel.
1105 
1106 o Padding Length (2 bytes) - Indicates the length of the
1107   Padding field in the payload, not including any other
1108   field.
1109 
1110 o Padding (variable length) - The padding that must be
1111   applied because this payload is encrypted separately from
1112   other parts of the packet.
1113 
1114 o Initial Vector (variable length) - The initial vector
1115   that has been used in packet encryption.  It needs to be
1116   used in the packet decryption as well.  What this field
1117   includes is implementation issue.  However, it is 
1118   recommended that it would be random data or, perhaps,
1119   a timestamp.  It is not recommended to use zero (0) as
1120   initial vector.  This field is not encrypted.  This field
1121   is not included into the padding calculation.  Length
1122   of this field equals the cipher's block size.  This field
1123   is, however, authenticated.
1124 .in 3
1125 
1126 
1127 .ti 0
1128 2.3.9 Channel Key Payload
1129 
1130 All traffic in channels are protected by channel specific keys.
1131 Channel Key Payload is used to distribute channel keys to all
1132 clients on the particular channel.  Channel keys are sent when
1133 the channel is created, when new user joins to the channel and
1134 whenever a user leaves a channel.  Server creates the new
1135 channel key and distributes it to the clients by encrypting this
1136 payload with the session key shared between the server and
1137 the client.  After that, client starts using the key received
1138 in this payload to protect the traffic on the channel.
1139