2.3 Communication in the Network .............................. 6
2.4 Channel Communication ..................................... 7
2.5 Router Connections ........................................ 7
+ 2.6 Backup Routers ............................................ XX
3 SILC Specification ............................................ 8
3.1 Client .................................................... 8
3.1.1 Client ID ........................................... 9
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.
distributed by SILC broadcast packets.
+.ti 0
+2.6 Backup Routers
+
+Backup routers may exist in the cell in addition of the primary router.
+However, they must not be active routers and act as routers in the cell.
+Only one router may be acting as primary router in the cell. In the case
+of failure of the primary router may one of the backup routers become
+active. The purpose of backup routers are in case of failure of the
+primary router to maintain working connections inside the cell and outside
+the cell and to avoid netsplits.
+
+Backup routers are normal servers in the cell that are prepared to take
+over the tasks of primary router if needed. They need to have at least
+one direct and active connection to the primary router of the cell.
+This communication channel is used to send the router information to
+the backup router. Backup router must know everything that the primary
+router knows to be able to take over the tasks of the primary router.
+It is the primary router's responsibility to feed the data to the backup
+router. If the backup router does not know all the data in the case of
+failure some connections may be lost. The primary router of the cell
+must consider the backup router being normal router server and feed the
+data accordingly.
+
+In addition of having direct connection to the primary router of the
+cell the backup router must also have connection to the same router
+the primary router of the cell has connected. However, it must not be
+active router connection meaning that the backup router must not use
+that channel as its primary route and it must not notify the router
+about having connected servers, channels and clients behind it. It
+merely connects to the router. This sort of connection is later
+referred as being passive connection. Some keepalive actions may be
+needed by the router to keep the connection alive.
+
+The primary router notifies its primary router about having backup
+routers in the cell by sending SILC_PACKET_CELL_ROUTERS packet. If
+and when the primary router of the cell becomes unresponsive, its
+primary router knows that there exists backup routers in the cell.
+After that it will start using the first backup router sent in the
+packet as router of that cell. In this case the backup router must
+notify its new primary router about the servers, channels and clients
+it has connected to it. The primary router knows that this server
+has become a router of the cell because of failure of the primary
+router in the cell. It must also cope with the fact that the servers,
+channels and clients that the new backup router announces are not
+really new, since they used to exist in the primary router of the
+cell.
+
+It is required that other normal servers has passive connections to
+the backup router(s) in the cell. Some keepalive actions may be needed
+by the server to keep the connection alive. After they notice the
+failure of the primary router they must start using the connection to
+the first backup router as their primary route.
+
+It is recommended that there would be at least one backup router in
+the cell. It is not recommended to have all servers in the cell acting
+as backup routers as it requires establishing several connections to
+several servers in the cell. Large cells can easily have several
+backup routers in the cell. The order of the backup routers are decided
+at the primary router of the cell and servers and backup servers in the
+cell must be configured accordingly. It is not required that the backup
+server is actually active server in the cell. Backup router may be spare
+server in the cell that does not accept normal client connections at all.
+It maybe reserved purely for the backup purposes. These, however, are
+cell management issues.
+
+If the first backup router is down as well and there is another backup
+router in the cell then it will start acting as the primary router as
+described above.
+
+
.ti 0
3. SILC Specification
.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
It is expected that some of the commands may be miss-used by clients
resulting various problems on the server side. Every implementation
should assure that commands may not be executed more than once, say,
-in two (2) seconds. This should be sufficient to prevent the miss-use
-of commands.
+in two (2) seconds. However, to keep response rate up, allowing for
+example five (5) commands before limiting is allowed. It is recommended
+that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN and
+SILC_COMMAND_LEAVE should be limited in all cases as they require
+heavy operations. This should be sufficient to prevent the miss-use of
+commands.
SILC commands are described in section 5 SILC Commands.
If the authentication method is password based, the Authentication
Data field includes the plaintext password. It is safe to send
-plaintext password since the entire payload is encrypted.
+plaintext password since the entire payload is encrypted. In this
+case the Public Data Lenght is set to zero (0).
If the authentication method is public key based (or certificate)
the Authentication Data is computed as follows:
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>
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
+are still secured with the old key. After these packets, the following
packets must be protected with the new key.
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.
Reply messages to the command:
- Max Arguments: 7
+ Max Arguments: 8
Arguments: (1) <Status Payload> (2) <Client ID>
(3) <nickname>[@<server>] (4) <username@host>
- (5) <real name> (6) [<channel list>]
- (7) [<idle time>]
+ (5) <real name> (6) [<Channel Payload
+ list>]
+ (7) [<user mode>] (8) [<idle time>]
+
This command may reply with several command reply messages to
form a list of results. In this case the status payload will
<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
Reply messages to the command:
- Max Arguments: 4
- Arguments: (1) <Status Payload> (2) <nickname>[@<server>]
- (3) <username@host> (4) [<real name>]
+ Max Arguments: 5
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) [<real name>]
This command may reply with several command reply messages to form
a list of results. In this case the status payload will include
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
13 SILC_COMMAND_OPER
Max Arguments: 2
- Arguments: (1) <username> (2) <authentication data>
+ Arguments: (1) <username> (2) <authentication payload>
This command is used by normal client to obtain server operator
privileges on some server or router. Note that router operator
must use SILCOPER command to obtain router level privileges.
The <username> is the username set in the server configurations
- as operator. The <authentication data> is the data that the
+ as operator. The <authentication payload> is the data that the
client is authenticated against. It may be passphrase prompted
- for user on client's screen or it may be public key
- authentication data (data signed with private key), or
- certificate.
+ 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:
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NOT_REGISTERED
- SILC_STATUS_ERR_BAD_PASSWORD
SILC_STATUS_ERR_AUTH_FAILED
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
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
SILC_STATUS_ERR_BAD_CLIENT_ID
SILC_STATUS_ERR_NOT_YOU
+ SILC_STATUS_ERR_PERM_DENIED
SILC_STATUS_ERR_UNKNOWN_MODE
- SILC_STATUS_ERR_NO_RECIPIENT
SILC_STATUS_ERR_NO_CLIENT_ID
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
all clients on the channel by sending SILC_NOTIFY_TYPE_CMODE_CHANGE
notify type.
-
Reply messages to the command:
Max Arguments: 2
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
client on the channel. Channel founder and channel operator
may set/unset (promote/demote) this mode.
-
Reply messages to the command:
Max Arguments: 3
23 SILC_COMMAND_SILCOPER
Max Arguments: 2
- Arguments: (1) <username> (2) <authentication data>
+ Arguments: (1) <username> (2) <authentication payload>
This command is used by normal client to obtain router operator
privileges (also known as SILC operator) on some router. Note
server operator privileges.
The <username> is the username set in the server configurations
- as operator. The <authentication data> is the data that the
+ as operator. The <authentication payload> is the data that the
client is authenticated against. It may be passphrase prompted
for user on client's screen or it may be public key
authentication data (data signed with private key), or
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
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
SILC_STATUS_ERR_NOT_REGISTERED
- SILC_STATUS_ERR_BAD_PASSWORD
SILC_STATUS_ERR_AUTH_FAILED
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).
31 SILC_STATUS_ERR_PERM_DENIED
- "Your host is not among the privileged". The client tried to
- register on server that does not allow this host to connect.
+ "Permission denied". Generic permission denied error status
+ to indicate disallowed access.
32 SILC_STATUS_ERR_BANNED_FROM_SERVER
projects / silc.git / blobdiff