This, on the other hand, leads to cellular like network, where routers
are in the center of the cell and servers are connected to the router.
-Following diagram represents SILC network topology.
+The following diagram represents SILC network topology.
its local server first to the router of the cell, and from the router
to the other server in the cell.
-Following diagram represents this scenario:
+The following diagram represents this scenario:
.in 25
the message is routed to the router server to which the destination
server belongs, if the local router is connected to destination router.
If there is no direct connection to the destination router, the local
-router routes the message to its primary route. Following diagram
+router routes the message to its primary route. The following diagram
represents message sending between cells.
.ti 0
3.2.3 SILC Server Ports
-Following ports has been assigned by IANA for the SILC protocol:
+The following ports has been assigned by IANA for the SILC protocol:
.in 10
silc 706/tcp SILC
commas (`,') and wildcard characters.
Channels can have operators that can administrate the channel and
-operate all of its modes. Following operators on channel exist on SILC
+operate all of its modes. The following operators on channel exist on SILC
network.
.in 6
definition of how it must be done. SILC has a mandatory algorithm that
must be supported in order to be compliant with this protocol.
-Following ciphers are defined in SILC protocol:
+The following ciphers are defined in SILC protocol:
.in 6
aes-256-cbc AES in CBC mode, 256 bit key (mandatory)
and to perform other tasks related to public key cryptography. The
public keys are also used in the SILC Key Exchange protocol [SILC3].
-Following public key algorithms are defined in SILC protocol:
+The following public key algorithms are defined in SILC protocol:
.in 6
rsa RSA (mandatory)
DSS is described in [Menezes]. The RSA must be implemented according
PKCS #1 [PKCS1]. The mandatory PKCS #1 implementation in SILC must be
-compliant to either PKCS #1 version 1.5 or newer with the following
+compliant to either PKCS #1 version 1.5 or newer with the the following
notes: The signature encoding is always in same format as the encryption
encoding regardles of the PKCS #1 version. The signature with appendix
(with hash algorithm OID in the data) must not be used in the SILC. The
section. They are also used in the SILC Key Exchange protocol defined
in the [SILC3].
-Following Hash algorithm are defined in SILC protocol:
+The following Hash algorithm are defined in SILC protocol:
sha1 SHA-1, length = 20 (mandatory)
md5 MD5, length = 16 (optional)
(MAC) of the packet data. See [SILC2] for details how to compute the
MAC.
-Following MAC algorithms are defined in SILC protocol:
+The following MAC algorithms are defined in SILC protocol:
.in 6
hmac-sha1-96 HMAC-SHA1, length = 12 (mandatory)
use compression which is the mode that must be supported by all SILC
implementations.
-Following compression algorithms are defined:
+The following compression algorithms are defined:
.in 6
none No compression (mandatory)
o Identifier (variable length) - Indicates the identifier
of the public key. This data can be used to identify
- the owner of the key. The identifier is of following
+ the owner of the key. The identifier is of the following
format:
UN User name
The version detection of both client and server is performed at the
connection phase while executing the SILC Key Exchange protocol. The
version identifier is exchanged between initiator and responder. The
-version identifier is of following format:
+version identifier is of the following format:
.in 6
SILC-<protocol version>-<software version>
.in 3
-The version strings are of following format:
+The version strings are of the following format:
.in 6
protocol version = <major>.<minor>
hashing the old key with hash function selected earlier in the SKE
protocol. If the digest length of the hash function is too short for the
key, then the key is distributed as described in section Processing the
-Key Material in [SILC3]. After both parties has regenerated the session
-key, both send SILC_PACKET_REKEY_DONE packet to each other. These packets
-are still secured with the old key. After these packets, following
-packets must be protected with the new key.
+Key Material in [SILC3].
+
+After both parties has regenerated the session key, both send
+SILC_PACKET_REKEY_DONE packet to each other. These packets are still
+secured with the old key. After these packets, the following packets
+must be protected with the new key. After sending the REKEY_DONE packet
+all subsequent sent packets must be encrypted with the new key. After
+receiving the REKEY_DONE packet all subsequent packets must be
+decrypted with the new key.
.ti 0
so that all users are searched. However, the server still must
search its locally connected clients. The router must send
this command to the server who owns the requested client. That
- server must reply to the command. Server should not send whois
+ server must reply to the command. Server must not send whois
replies to the client until it has received the reply from its
router.
Max Arguments: 8
Arguments: (1) <Status Payload> (2) <Client ID>
(3) <nickname>[@<server>] (4) <username@host>
- (5) <real name> (6) [<channel list>]
+ (5) <real name> (6) [<Channel Payload
+ list>]
(7) [<user mode>] (8) [<idle time>]
<count> option were defined in the query there will be only
<count> many replies from the server.
+ The server may return the list of channel the client has joined.
+ In this case the list is list of Channel Payloads. The Mode Mask
+ in the Channel Payload (see [SILC2] and section 2.3.2.3 for the
+ Channel Payload) is the client's mode on the channel. The list
+ is encoded by adding the Channel Payloads one after the other.
+
Status messages:
SILC_STATUS_OK
SILC_STATUS_ERR_TOO_MANY_PARAMS
-
-
2 SILC_COMMAND_WHOWAS
Max Arguments: 2
5 SILC_COMMAND_LIST
- Max Arguments: 2
- Arguments: (1) [<Channel ID>] [<server>]
+ Max Arguments: 1
+ Arguments: (1) [<Channel ID>]
- The list command is used to list channels and their topics on
+ The list command is used to list channels and their topics on the
current server. If the <Channel ID> parameter is used, only the
status of that channel is displayed. Secret channels are not
listed at all. Private channels are listed with status indicating
- that the channel is private.
-
- If the <server> argument is specified the specified server's
- channels are listed. In this case the command must be sent to
- the server who owns the channel that was requested.
+ that the channel is private. Router may reply with all channels
+ it knows about.
Reply messages to the command:
- Max Arguments: 4
+ Max Arguments: 5
Arguments: (1) <Status Payload> (2) <Channel ID>
- (3) <channel> (4) <topic>
+ (3) <channel> (4) [<topic>]
+ (5) [<user count>]
This command may reply with several command reply messages to form
a list of results. In this case the status payload will include
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_REGISTERED
SILC_STATUS_ERR_TOO_MANY_PARAMS
- SILC_STATUS_ERR_NO_SUCH_CHANNEL
SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
SILC_STATUS_ERR_NO_SUCH_SERVER
for that channel will be changed, if the channel modes permit
this action.
+ After setting the topic the server must send the notify type
+ SILC_NOTIFY_TYPE_TOPIC_SET to its primary router and then to
+ the channel which topic was changed.
+
Reply messages to the command:
Max Arguments: 2
7 SILC_COMMAND_INVITE
- Max Arguments: 2
- Arguments: (1) <Client ID> (2) <Channel ID>
+ Max Arguments: 4
+ Arguments: (1) <Channel ID> (2) [<Client ID>]
+ (3) [<adding client>] (4) [<removing client>]
This command is used to invite other clients to join to the
channel. The <Client ID> argument is the target client's ID that
is being invited. The <Channel ID> is the Channel ID of the
requested channel. The sender of this command must be on the
- channel. This command must fail if the requested channel does
- not exist, the requested client is already on the channel or if
- the channel is invite only channel and the caller of this command
- does not have at least channel operator privileges.
+ channel. The server must also send the notify type
+ SILC_NOTIFY_TYPE_INVITE to its primary router and then to the
+ client indicated by the <Client ID>.
+
+ The <adding client> and <removing client> can be used to add to
+ and remove from the invite list. The format of the <adding client>
+ and <removing client> is as follows:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ When adding to or removing from the invite list the server must
+ send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router
+ and must not send it to the client which was added to the list.
+ The client which executes this command must have at least channel
+ operator privileges to be able to add to or remove from the invite
+ list. The wildcards may be used with this command. If adding or
+ removing from than one clients then the lists are an comma (`,')
+ separated list.
+
+ Note that the <Client ID> provided must be resolved into correct
+ nickname and hostname and add to the invite list before sending
+ the notify packet.
+
+ When this command is given with only <Channel ID> argument then
+ the command merely returns the invite list of the channel. This
+ command must fail if the requested channel does not exist, the
+ requested <Client ID> is already on the channel or if the channel
+ is invite only channel and the caller of this command does not
+ have at least channel operator privileges.
Reply messages to the command:
- Max Arguments: 2
- Arguments: (1) <Status Payload>
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<invite list>]
- This command replies only with Status Payload.
+ This command replies with the invite list of the channel if it
+ exists.
Status messages:
SILC_STATUS_ERR_NO_CHANNEL_ID
SILC_STATUS_ERR_NOT_ON_CHANNEL
SILC_STATUS_ERR_USER_ON_CHANNEL
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
8 SILC_COMMAND_QUIT
give to the removed client some information why it was removed
from the network.
+ When killing a client the router must first send notify type
+ SILC_NOTIFY_TYPE_KILLED to all channels the client has joined.
+ The packet must not be sent to the killed client on the channel.
+ Then, the router must send the same notify type to its primary
+ router. Finally, the router must send the same notify type to
+ the client who was killed.
+
Reply messages to the command:
Max Arguments: 1
10 SILC_COMMAND_INFO
- Max Arguments: 1
- Arguments: (1) [<server>]
+ Max Arguments: 2
+ Arguments: (1) [<server>] (2) [<Server ID>]
This command is used to fetch various information about a server.
If <server> argument is specified the command must be sent to
the requested server.
+ If the <Server ID> is specified the server information if fetched
+ by the provided Server ID.
+
Reply messages to the command:
- Max Arguments: 3
+ Max Arguments: 4
Arguments: (1) <Status Payload> (2) <Server ID>
- (3) <string>
+ (3) <server name> (4) <string>
This command replies with the Server ID of the server and a
string which tells the information about the server.
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NO_SUCH_SERVER
+ SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+ SILC_STATUS_ERR_NO_SERVER_ID
11 SILC_COMMAND_CONNECT
for user on client's screen or it may be public key or certificate
authentication data (data signed with private key).
+ After changing the mode server must send the notify type
+ SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
Reply messages to the command:
Max Arguments: 1
Reply messages to the command:
Max Arguments: 14
- Arguments: (1) <Status Payload> (2) <channel>
- (3) <Channel ID> (4) <Client ID>
- (5) <channel mode mask> (6) <created>
- (7) <Channel Key Payload> (8) [<ban mask>]
- (9) [<invite list>] (10) [<topic>]
- (11) [<hmac>] (12) <list count>
- (13) <Client ID list> (14) <client mode list>
+ Arguments: (1) <Status Payload> (2) <channel>
+ (3) <Channel ID> (4) <Client ID>
+ (5) <channel mode mask> (6) <created>
+ (7) [<Channel Key Payload>] (8) [<ban list>]
+ (9) [<invite list>] (10) [<topic>]
+ (11) [<hmac>] (12) <list count>
+ (13) <Client ID list> (14) <client mode list>
This command replies with the channel name requested by the
client, channel ID of the channel and topic of the channel
and/or invite list is set they are sent as well.
The <list count>, <Client ID list> and <client mode list> are
- the clients curerntly on the channel and their modes on the
- channel.
+ the clients currently on the channel and their modes on the
+ channel. The <Client ID list> is formed by adding the ID Payloads
+ one after the other. The <client mode list> is formed by adding
+ 32 bit MSB first order values one after the other.
Client receives the channel key in the reply message as well
inside <Channel Key Payload>.
Reply messages to the command:
- Max Arguments: 2
- Arguments: (1) <Status Payload> (2) [<motd>]
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Server ID>
+ (3) [<motd>]
This command replies with the motd message if it exists.
locally so that the mode setting/unsetting would work without
problems. Client may change only its own modes.
- Following client modes are defined:
+ After changing the mode server must send the notify type
+ SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
+ The following client modes are defined:
0x0000 SILC_UMODE_NONE
privileges by SILC_COMMAND_SILCOPER command. Client
may unset the mode itself.
+
Reply messages to the command:
Max Arguments: 2
17 SILC_COMMAND_CMODE
- Max Arguments: 8
+ Max Arguments: 6
Arguments: (1) <Channel ID> (2) <channel mode mask>
(3) [<user limit>] (4) [<passphrase>]
- (5) [<ban mask>] (6) [<invite list>]
- (7) [<cipher>] (8) [<hmac>]
+ (5) [<cipher>] (6) [<hmac>]
This command is used by client to set or change channel flags on
a channel. Channel has several modes that set various properties
When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
type is distributed to the channel.
- Following channel modes are defined:
+ The following channel modes are defined:
0x0000 SILC_CMODE_NONE
to set/unset this mode.
- 0x0080 SILC_CMODE_BAN
-
- Ban mask has been set to the channel. The ban mask
- may be used to ban specific clients to join the channel.
- The <ban mask> argument is the set ban mask. When
- unsetting a ban mask the mask must be provided as
- argument. Channel founder and channel operator may
- set/unset this mode. Channel founder may not be
- added to the ban list. <ban mask> is an comma (`,')
- separated list of banned clients in the following format:
-
- [<nickname>[@<server>]!][<username>]@[<hostname>]
-
- Wildcards maybe used when banning clients.
-
- Typical implementation would use [+|-]b on user interface
- to set/unset this mode.
-
-
- 0x0100 SILC_CMODE_INVITE_LIST
-
- Invite list has been set to the channel. The invite list
- can be used to mark the clients that is able to join
- channel without being invited when the channel is set to
- be invite-only channel. The <invite list> argument is the
- set invite mask. When unsetting entry from the invite list
- the entry must be provided as argument. Channel founder and
- channel operator may set/unset this mode. The <invite list>
- is command (`,') separated list of invited clients in the
- following format:
-
- [<nickname>[@<server>]!][<username>]@[<hostname>]
-
- Wildcards maybe used when setting the invite list.
-
- Typical implementation would use [+|-]I on user interface
- to set/unset this mode.
-
-
- 0x0200 SILC_CMODE_CIPHER
+ 0x0080 SILC_CMODE_CIPHER
Sets specific cipher to be used to protect channel
traffic. The <cipher> argument is the requested cipher.
to set/unset this mode.
- 0x0400 SILC_CMODE_HMAC
+ 0x0100 SILC_CMODE_HMAC
Sets specific hmac to be used to compute the MACs of the
channel message. The <hmac> argument is the requested hmac.
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
- 19 SILC_COMMAND_CUMODE
+ 18 SILC_COMMAND_CUMODE
Max Arguments: 3
Arguments: (1) <Channel ID> (2) <mode mask>
When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
type is distributed to the channel.
- Following channel modes are defined:
+ The following channel modes are defined:
0x0000 SILC_CUMODE_NONE
channel. If <comment> is provided it will be sent to the removed
client.
+ After kicking the client the server must send the notify type
+ SILC_NOTIFY_TYPE_KICKED to the channel and to its primary router.
+ The channel key must also be re-generated after kicking.
+
Reply messages to the command:
Max Arguments: 1
SILC_STATUS_ERR_NO_SERVER_PRIV
-
-
-
21 SILC_COMMAND_CLOSE
Max Arguments: 2
local properties, such as, local connections and normal server
administration.
+ After changing the mode server must send the notify type
+ SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
+
Reply messages to the command:
Max Arguments: 1
Arguments: (1) <Channel ID>
This command is used by client to leave a channel the client is
- joined to. After a client has leaved the channel the server
- must create new key for the channel and distribute to all clients
- still currently on the channel.
+ joined to.
+
+ When leaving the channel the server must send the notify type
+ SILC_NOTIFY_TYPE_LEAVE to its primary router and to the channel.
+ The channel key must also be re-generated when leaving the channel
+ and distribute it to all clients still currently on the channel.
Reply messages to the command:
SILC_STATUS_ERR_NOT_ON_CHANNEL
- 26 - 199
+ 26 SILC_COMMAND_BAN
+
+ Max Arguments: 3
+ Arguments: (1) <Channel ID> (2) [<adding client>]
+ (3) [<removing client>]
+
+ This command is used to manage the ban list of the channel
+ indicated by the <Channel ID>. A client that is banned from
+ channel is no longer able to join the channel. The client which
+ is executing this command must have at least channel operator
+ privileges on the channel.
+
+ The <adding client> and <removing client> are used to add to and
+ remove from the ban list. The format of the <adding client> and
+ the <removing client> is of following format:
+
+ [<nickname>[@<server>]!][<username>]@[<hostname>]
+
+ The server must send the notify type SILC_NOTIFY_TYPE_BAN to its
+ primary router after adding to or removing from the ban list.
+ The wildcards may be used with this command. If adding or removing
+ from than one clients then the lists are an comma (`,') separated
+ list.
+
+ If this command is executed without the ban arguments the command
+ merely replies with the current ban list.
+
+
+ Reply messages to the command:
+
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) [<ban list>]
+
+ This command replies with the <Channel ID> of the channel and
+ the current <ban list> of the channel if it exists.
+
+ Status messages:
+
+ SILC_STATUS_OK
+ SILC_STATUS_ERR_NOT_REGISTERED
+ SILC_STATUS_ERR_TOO_MANY_PARAMS
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
+ SILC_STATUS_ERR_NO_CHANNEL_ID
+ SILC_STATUS_ERR_NOT_ON_CHANNEL
+ SILC_STATUS_ERR_NO_CHANNEL_PRIV
+
+
+ 27 - 199
Currently undefined commands.
Command Status Payload is sent in command reply messages to indicate
the status of the command. The payload is one of argument in the
command thus this is the data area in Command Argument Payload described
-in [SILC2]. The payload is only 2 bytes of length. Following diagram
+in [SILC2]. The payload is only 2 bytes of length. The following diagram
represents the Command Status Payload (field is always in MSB order).
projects / silc.git / blobdiff