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
sent only to the clients which is joined on the channel where
the target client is on.
- Max Arguments: 3
- Arguments: (1) <ID Payload> (2) <mode mask>
- (3) <Target Client ID>
+ Max Arguments: 4
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) <Target Client ID> (3) [<founder pubkey>]
The <ID Payload> is the ID (usually Client ID but it can be
Server ID as well when the router is enforcing user's mode
change) of the entity which changed the mode. The <mode mask>
is the new mode mask of the channel. The <Target Client ID>
- is the client which mode was changed.
+ is the client which mode was changed. The <founder pubkey>
+ is the public key of the channel founder and is sent only
+ when first setting the channel founder mode using the
+ SILC_COMMAND_CUMODE command, and when sending this notify.
9 SILC_NOTIFY_TYPE_MOTD
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.
- 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.
+ 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
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
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