protocol describes the packet types and packet payloads which defines
the contents of the packets. The protocol provides secure binary packet
protocol that assures that the contents of the packets are secured and
-authenticated.
+authenticated. The packet protocol is designed to be compact to avoid
+unnecessary overhead as much as possible. This makes the SILC suitable
+also in environment of low bandwith requirements such as mobile networks.
+All packet payloads can also be compressed to further reduce the size
+of the packets.
The basis of SILC protocol relies in the SILC packets and it is with
out a doubt the most important part of the protocol. It is also probably
section 2.12 Packet Broadcasting for description of
packet broadcasting.
+
+ Compressed 0x08
+
+ Marks that the payload of the packet is compressed.
+ The sender of the packet marks this flag when it
+ compresses the payload, and any server or router
+ en route to the receipient MUST NOT unset this flag.
+ See section 2.8 Packet Compression for description of
+ packet compressing.
+
.in 3
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Status | |
++-+-+-+-+-+-+-+-+ +
| |
~ Disconnect Message ~
| |
.ce
Figure 7: Disconnect Payload
-
-
-
.in 6
-o Disconnect Message (variable length) - Human readable
- reason of the disconnection.
+o Status (1 byte) - Indicates the Status Type, defined in [SILC3]
+ for the reason of disconnection.
+
+o Disconnect Message (variable length) - Human readable UTF-8
+ encoded string indicating reason of the disconnection. This
+ MAY be omitted.
.in 3
to the clients which is joined on the channel which mode was
changed.
- Max Arguments: 5
+ Max Arguments: 6
Arguments: (1) <ID Payload> (2) <mode mask>
(3) [<cipher>] (4) <[hmac>]
- (5) [<passphrase>]
+ (5) [<passphrase>] (6) [<founder public key>]
The <ID Payload> is the ID (usually Client ID but it can be
Server ID as well when the router is enforcing channel mode
packet will force the new channel key change anyway. The <hmac>
argument is important since the client is responsible of setting
the new HMAC and the hmac key into use. The <passphrase> is
- the passphrase of the channel, if it was now set.
+ the passphrase of the channel, if it was now set. The <founder
+ public key> argument is sent when the founder mode on the
+ channel was set. All routers and servers that receive the packet
+ MUST save the founder's public key so that the founder can
+ reclaim the channel founder rights back for the channel on any
+ server in the network.
8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
<removing client> is defined in the [SILC4] with SILC_COMMAND_BAN
command.
+
+16 SILC_NOTIFY_TYPE_ERROR
+
+ Sent when an error occurs during processing some SILC procedure.
+ This is not used when error occurs during command processing, see
+ [SILC3] for more information about commands and command replies.
+ This type is sent directly to the sender of the packet whose packet
+ caused the error. See [SILC1] for definition when this type
+ can be sent.
+
+ Max Arguments: 256
+ Arguments: (1) <Status Type> (n) [...]
+
+ The <Status Type> is the error type defined in [SILC3]. Note that
+ same types are also used with command replies to indicate the
+ status of a command. Both commands and this notify type share
+ same status types. Rest of the arguments are status type
+ dependent and are specified with those status types that can be
+ sent currently inside this notify type in [SILC3]. The <Status
+ Type> is of size of 1 byte.
+
+
+17 SILC_NOTIFY_TYPE_WATCH
+
+ Sent to indicate change in a watched user. Client can set
+ nicknames to be watched with SILC_COMMAND_WATCH command, and
+ receive notifications when they login to network, signoff from
+ the network or their user mode is changed. This notify type
+ is used to deliver these notifications. The notify type is
+ sent directly to the watching client.
+
+ Max Arguments: 4
+ Arguments: (1) <Client ID> (2) [<nickname>]
+ (3) <user mode> (4) [<Notify Type>]
+
+ The <Client ID> is the user's Client ID which is being watched,
+ and the <nickname> is its nickname. If the client just
+ changed the nickname, then <nickname> is the new nickname, but
+ the <Client ID> is the old client ID. The <user mode> is the
+ user's current user mode. The <Notify Type> can be same as the
+ Notify Payload's Notify Type, and is 16 bit MSB first order value.
+ If provided it may indicate the notify that occurred for the
+ client. If client logged in to the network the <Notify Type>
+ MUST NOT be present.
.in 3
Notify types starting from 16384 are reserved for private notify
message types.
+Router server which receives SILC_NOTIFY_TYPE_SIGNOFF,
+SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED,
+SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
+MUST chech whether someone in the local cell is watching the nickname
+the client has, and send the SILC_NOTIFY_TYPE_WATCH notify to the
+watcher, unless the client in case has the SILC_UMODE_REJECT_WATCHING
+user mode set. If the watcher client and the client that was
+watched is same the notify SHOULD NOT be sent.
+
.ti 0
2.3.8 Error Payload
Private range for free use.
o Message Length (2 bytes) - Indicates the length of the
- the Message Data field in the payload, not including any
+ Message Data field in the payload, not including any
other field.
o Message Data (variable length) - The actual message to
other parts of the packet.
o MAC (variable length) - The MAC computed from the
- Message Length, Message Data, Padding Length, Padding and
- Initial Vector fields. This protects the integrity of the
- plaintext channel message. The receiver can verify from
- the MAC whether the message decrypted correctly. Also, if
- more than one private key has been set for the channel, the
- receiver can verify which of the keys decrypted the message
- correctly. Note that, this field is encrypted and MUST
- be added to the padding calculation.
+ Message Flags, Message Length, Message Data, Padding Length,
+ Padding and Initial Vector fields in that order. This
+ protects the integrity of the plaintext channel message.
+ The receiver can verify from the MAC whether the message
+ decrypted correctly. Also, if more than one private key
+ has been set for the channel, the receiver can verify which
+ of the keys decrypted the message correctly. Note that,
+ this field is encrypted and MUST be added to the padding
+ calculation.
o Initial Vector (variable length) - The initial vector
that has been used in packet encryption. It needs to be
used in the packet decryption as well. What this field
includes is implementation issue. However, it is
- RECOMMENDED that it would be random data or, perhaps,
+ RECOMMENDED that it would be random data, or perhaps
a timestamp. It is NOT RECOMMENDED to use zero (0) as an
initial vector. This field is not encrypted. This field
is not included into the padding calculation. Length
of this field equals the cipher's block size. This field
- is, however, authenticated.
+ is, however authenticated.
.in 3
the packet is received and decrypted the data area MUST be decompressed.
Note that the true sender of the packet MUST apply the compression and
the true receiver of the packet MUST apply the decompression. Any
-server or router en route MUST NOT decompress the packet.
+server or router en route SHOULD NOT decompress the packet.
.ti 0
projects / silc.git / blobdiff