.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XX XXXXXX 2001
+.ds RH 13 November 2001
.ds CH
.na
.hy 0
.in 0
.nf
-Network Working Group P. Riikonen
+Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-04.txt XX XXXXXXX 2001
-Expires: XXXXXXX
+draft-riikonen-silc-spec-04.txt 13 November 2001
+Expires: 13 May 2002
.in 3
2.3 Communication in the Network .............................. 6
2.4 Channel Communication ..................................... 7
2.5 Router Connections ........................................ 7
-3 SILC Specification ............................................ 10
- 3.1 Client .................................................... 10
- 3.1.1 Client ID ........................................... 10
- 3.2 Server .................................................... 11
- 3.2.1 Server's Local ID List .............................. 12
- 3.2.2 Server ID ........................................... 13
- 3.2.3 SILC Server Ports ................................... 14
- 3.3 Router .................................................... 14
- 3.3.1 Router's Local ID List .............................. 14
- 3.3.2 Router's Global ID List ............................. 15
- 3.3.3 Router's Server ID .................................. 15
- 3.4 Channels .................................................. 16
- 3.4.1 Channel ID .......................................... 17
- 3.5 Operators ................................................. 17
- 3.6 SILC Commands ............................................. 18
- 3.7 SILC Packets .............................................. 18
- 3.8 Packet Encryption ......................................... 19
- 3.8.1 Determination of the Source and the Destination ..... 19
- 3.8.2 Client To Client .................................... 20
- 3.8.3 Client To Channel ................................... 21
- 3.8.4 Server To Server .................................... 22
- 3.9 Key Exchange And Authentication ........................... 22
- 3.9.1 Authentication Payload .............................. 22
- 3.10 Algorithms ............................................... 24
- 3.10.1 Ciphers ............................................ 24
- 3.10.2 Public Key Algorithms .............................. 25
- 3.10.3 Hash Functions ..................................... 26
- 3.10.4 MAC Algorithms ..................................... 26
- 3.10.5 Compression Algorithms ............................. 26
- 3.11 SILC Public Key .......................................... 27
- 3.12 SILC Version Detection ................................... 29
- 3.13 Backup Routers ........................................... 8
- 3.13.1 Switching to Backup Router ......................... 8
- 3.13.2 Resuming Primary Router ............................ 8
- 3.13.3 Discussion on Backup Router Scheme ................. 8
-4 SILC Procedures ............................................... 30
- 4.1 Creating Client Connection ................................ 30
- 4.2 Creating Server Connection ................................ 31
- 4.2.1 Announcing Clients, Channels and Servers ............ 32
- 4.3 Joining to a Channel ...................................... 33
- 4.4 Channel Key Generation .................................... 34
- 4.5 Private Message Sending and Reception ..................... 34
- 4.6 Private Message Key Generation ............................ 35
- 4.7 Channel Message Sending and Reception ..................... 35
- 4.8 Session Key Regeneration .................................. 36
- 4.9 Command Sending and Reception ............................. 37
- 4.10 Closing Connection ....................................... 37
-5 Security Considerations ....................................... 38
-6 References .................................................... 38
-7 Author's Address .............................................. 40
+3 SILC Specification ............................................ 8
+ 3.1 Client .................................................... 8
+ 3.1.1 Client ID ........................................... 9
+ 3.2 Server .................................................... 10
+ 3.2.1 Server's Local ID List .............................. 10
+ 3.2.2 Server ID ........................................... 11
+ 3.2.3 SILC Server Ports ................................... 12
+ 3.3 Router .................................................... 12
+ 3.3.1 Router's Local ID List .............................. 12
+ 3.3.2 Router's Global ID List ............................. 13
+ 3.3.3 Router's Server ID .................................. 14
+ 3.4 Channels .................................................. 14
+ 3.4.1 Channel ID .......................................... 16
+ 3.5 Operators ................................................. 16
+ 3.6 SILC Commands ............................................. 16
+ 3.7 SILC Packets .............................................. 17
+ 3.8 Packet Encryption ......................................... 17
+ 3.8.1 Determination of the Source and the Destination ..... 17
+ 3.8.2 Client To Client .................................... 18
+ 3.8.3 Client To Channel ................................... 19
+ 3.8.4 Server To Server .................................... 20
+ 3.9 Key Exchange And Authentication ........................... 20
+ 3.9.1 Authentication Payload .............................. 20
+ 3.10 Algorithms ............................................... 22
+ 3.10.1 Ciphers ............................................ 22
+ 3.10.2 Public Key Algorithms .............................. 23
+ 3.10.3 Hash Functions ..................................... 24
+ 3.10.4 MAC Algorithms ..................................... 24
+ 3.10.5 Compression Algorithms ............................. 25
+ 3.11 SILC Public Key .......................................... 25
+ 3.12 SILC Version Detection ................................... 27
+ 3.13 Backup Routers ........................................... 28
+ 3.13.1 Switching to Backup Router ......................... 29
+ 3.13.2 Resuming Primary Router ............................ 30
+ 3.13.3 Discussion on Backup Router Scheme ................. 32
+4 SILC Procedures ............................................... 33
+ 4.1 Creating Client Connection ................................ 33
+ 4.2 Creating Server Connection ................................ 34
+ 4.2.1 Announcing Clients, Channels and Servers ............ 35
+ 4.3 Joining to a Channel ...................................... 36
+ 4.4 Channel Key Generation .................................... 37
+ 4.5 Private Message Sending and Reception ..................... 38
+ 4.6 Private Message Key Generation ............................ 38
+ 4.7 Channel Message Sending and Reception ..................... 39
+ 4.8 Session Key Regeneration .................................. 39
+ 4.9 Command Sending and Reception ............................. 40
+ 4.10 Closing Connection ....................................... 41
+5 Security Considerations ....................................... 41
+6 References .................................................... 42
+7 Author's Address .............................................. 44
Every router has their primary route which is a connection to another
router in the network. Unless there is only two routers in the network
must not routers use each other as their primary routes. The router
-connections in the network must form a circular.
+connections in the network must form a ring.
The issue of router connections are very important especially with SILC
broadcast packets. Usually all router wide information in the network is
-distributed by SILC broadcast packets.
+distributed by SILC broadcast packets. This sort of ring network, with
+ability to have other direct routes in the network cause interesting
+routing problems. The [SILC2] discusses the routing of packets in this
+sort of network in more detail.
.ti 0
connection to router on same port. Normal server MUST NOT connect to other
cell's router except in situations where its cell's router is unavailable.
-Servers and routers in the SILC network are considered to be trusted.
-With out a doubt, servers that are set to work on ports above 1023 are
-not considered to be trusted. Also, the service provider acts important
-role in the server's trustworthy.
-
.ti 0
3.2.1 Server's Local ID List
-
-
-
-
-
.ti 0
3.3.3 Router's Server ID
packets are what actually makes the protocol. Packets in SILC network
are always encrypted using, usually the shared secret session key
or some other key, for example, channel key, when encrypting channel
-messages. The SILC Packet Protocol is a wide protocol and is described
+messages. It is not possible to send packet in SILC network without
+encryption. The SILC Packet Protocol is a wide protocol and is described
in [SILC2]. This document does not define or describe details of
SILC packets.
-
-
-
.ti 0
3.8 Packet Encryption
server to become server operator. In this case, Authentication Payload is
used.
-
-
-
-
-
-
-
-
-
-
The format of the Authentication Payload is as follows:
o Public Data (variable length) - This is defined only if
the authentication method is public key. If it is any other
- this field does not exist and the Public Data Length field
- is set to zero (0).
+ this field MAY include a random data for padding purposes.
+ However, in this case the field MUST be ignored by the
+ receiver.
When the authentication method is public key this includes
128 to 4096 bytes of non-zero random data that is used in
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. In this
-case the Public Data Length is set to zero (0).
+case the Public Data Length is set to zero (0), but MAY also include
+random data for padding purposes. It is also RECOMMENDED that maximum
+amount of padding is applied to SILC packet when using password based
+authentication. This way it is not possible to approximate the length
+of the password from the encrypted packet.
If the authentication method is public key based (or certificate)
the Authentication Data is computed as follows:
Additional public key algorithms MAY be defined to be used in SILC.
-
-
.ti 0
3.10.3 Hash Functions
Additional MAC algorithms MAY be defined to be used in SILC.
+
+
.ti 0
3.10.5 Compression Algorithms
use compression which is the mode that must be supported by all SILC
implementations.
-
-
The following compression algorithms are defined:
.in 6
Protocol version MAY provide both major and minor version. Currently
implementations MUST set the protocol version and accept the protocol
-version as SILC-1.0-<software version>.
+version as SILC-1.0-<software version>. If new protocol version causes
+in compatibilities with older version the the <minor> versio number MUST
+be incremented. The <major> is incremented if new protocol version is
+fully incompatible.
Software version MAY provide major, minor and build version. The
software version MAY be freely set and accepted.
its position as primary router when it comes back online. The backup
router that is now acting as primary router of the cell must constantly
try to connect to the original primary router of the cell. It is
-recommended that it would try to reconnect every 2 minutes to the primary
-router.
-
-When the connection is established to the primary router, the backup
-router must announce all of its servers, clients, channels and other
-information to the primary router. It must then send packet
-SILC_PACKET_RESUME_ROUTER to all of the server connections. This
-packet is used to tell the servers that they must reconnect to the
-original primary router of the cell. When they have established the
-connection to the router they must send the same packet back to the
-primary router as an indication that they have successfully connected
-back to the primary router. Then, the primary router will send the
-same packet to the primary router as an indication that it will pass
-over the tasks of being primary router of the cell and will revert back
-as being normal server (but still existing as backup router) in the cell.
-
-When the primary router receives the SILC_PACKET_RESUME_ROUTER packet
-it must announce all of its servers, clients, channels and other information
-to its primary router.
-
-All the connections that were used as primary routes will revert back
-as being passive connections.
+RECOMMENDED that it would try to reconnect in 30 second intervals to
+the primary router.
+
+When the connection is established to the primary router the backup
+resuming protocol is executed. The protocol is advanced as follows:
+
+ 1. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+ value 1 the primary router that came back online. The packet
+ will indicate the primary router has been replaced by the backup
+ router. After sending the packet the backup router will announce
+ all of its channels, channel users, modes etc. to the primary
+ router.
+
+ 2. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+ value 2 to its current primary router to indicate that it will
+ resign as being primary router. Then, backup router sends the
+ SILC_PACKET_RESUME_ROUTER packet with type value 1 to all
+ connected servers to also indicate that it will resign as being
+ primary router.
+
+ 3. Backup router also send SILC_PACKET_RESUME_ROUTER packet with
+ type value 2 to the router that is using the backup router
+ currently as its primary router.
+
+ 4. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+ with type value 1 or 2 must reconnect immediately to the
+ primary router of the cell that came back online. After they
+ have created the connection they MUST NOT use that connection
+ as active primary route but still route all packets to the
+ backup router. After the connection is created they MUST send
+ SILC_PACKET_RESUME_ROUTER with type value 3 back to the
+ backup router. The session ID value found in the first packet
+ MUST be set in this packet.
+
+ 5. Backup router MUST wait for all packets with type value 3 before
+ it continues with the protocol. It knows from the session ID values
+ set in the packet when it have received all packets. The session
+ value should be different in all packets it have send earlier.
+ After the packets is received the backup router sends the
+ SILC_PACKET_RESUME_ROUTER packet with type value 4 to the
+ primary router that came back online. This packet will indicate
+ that the backup router is now ready to resign as being primary
+ router. The session ID value in this packet MUST be the same as
+ in first packet sent to the primary router. During this time
+ the backup router should still route all packets it is receiving
+ from server connections.
+
+ 6. The primary router receives the packet and send the
+ SILC_PACKET_RESUME_ROUTER with type value 5 to all connected servers
+ including the backup router. It also sends the packet with type
+ value 6 to its primary router, and to the router that is using
+ it as its primary router. The Session ID value in this packet
+ SHOULD be zero (0).
+
+ 7. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+ with type value 5 or 6 must switch their primary route to the
+ new primary router and remove the route for the backup router, since
+ it is not anymore the primary router of the cell. They must also
+ update their local database to understand that the clients are
+ not originated from the backup router but from the locally connected
+ servers. After that they MUST announce their channels, channel
+ users, modes etc. to the primary router. They must not use the
+ backup router connection after this and the connection is considered
+ to be passive connection. The implementations SHOULD be able
+ to disable the connection without closing the actual link.
+
+After this protocol is executed the backup router is now again normal
+server in the cell that has the backup link to the primary router. The
+primary router feeds the router specific data again to the backup router.
+All server connections in the backup router are considered passive
+connections.
+
+When the primary router of the cell comes back online and connects
+to its primary router, the remote primary router must send the
+SILC_PACKET_RESUME_ROUTER with type value 20 indicating that the
+connection is not allowed since the router has been replaced by an
+backup router. The session ID value in this packet SHOULD be zero (0).
+When the router receives this packet it must not use the connection
+as active connection but to understand that it cannot act as primary
+router in the cell. It must wait that the backup router connects to
+it, and the backup resuming protocol is executed.
+
+The following type values has been defined for SILC_PACKET_RESUME_ROUTER
+packet:
+
+ 1 SILC_SERVER_BACKUP_START
+ 2 SILC_SERVER_BACKUP_START_GLOBAL
+ 3 SILC_SERVER_BACKUP_START_CONNECTED
+ 4 SILC_SERVER_BACKUP_START_ENDING
+ 5 SILC_SERVER_BACKUP_START_RESUMED
+ 6 SILC_SERVER_BACKUP_START_GLOBAL
+ 20 SILC_SERVER_BACKUP_START_REPLACED
+
+If any other value is found in the type field the packet must be
+discarded. The SILC_PACKET_RESUME_ROUTER packet and its payload
+is defined in [SILC2].
.ti 0
is written on the subject.
-
.ti 0
4 SILC Procedures
The router MUST also announce the local servers by compiling list of
ID Payloads into the SILC_PACKET_NEW_ID packet.
+Also, clients' modes (user modes in SILC) MUST be announced. This is
+done by compiling a list of Notify Payloads with the
+SILC_NOTIFY_UMODE_CHANGE nofity type into the SILC_PACKET_NOTIFY packet.
+
+Also, channel's topics MUST be announced by compiling a list of Notify
+Payloads with the SILC_NOTIFY_TOPIC_SET notify type into the
+SILC_PACKET_NOTIFY packet.
+
The router which receives these lists MUST process them and broadcast
the packets to its primary route.
distribute the message to all clients on the channel by sending the
channel message destined explicitly to a client on the channel.
+See the [SILC2] for description of channel messege routing for router
+servers.
+
See [SILC2] for description of channel message encryption and decryption
process.
MUST be protected with the new key.
-
-
.ti 0
4.9 Command Sending and Reception
on the security and the integrity of the servers and administrators that
are running the service. It is recommended that some form of registration
is required by the server and router administrator prior acceptance to
-the SILC Network. The clients should be able to trust the servers they
-are using.
+the SILC Network. Even though, the SILC protocol is secure in a network
+of mutual distrust between clients, servers, routers and adminstrators
+of the servers, the client should be able to trust the servers they are
+using if they whish to do so.
It however must be noted that if the client requires absolute security
-by not trusting any of the servers or routers in the SILC Network, can
+by not trusting any of the servers or routers in the SILC Network, it can
be accomplished by negotiating private keys outside the SILC Network,
-either using SKE or some other key negotiation protocol, or to use some
+either using SKE or some other key exchange protocol, or to use some
other external means for distributing the keys. This applies for all
-messages, private messages and channel messages. It is important to note
-that SILC, like any other security protocol is not full proof system and
-cannot secure from insecure environment; the SILC servers and routers could
-very well be compromised. However, to provide acceptable level of security
-and usability for end user the protocol uses many times session keys or
-other keys generated by the servers to secure the messages. If this is
-unacceptable for the client or end user, the private keys negotiatied
-outside the SILC Network should always be used. In the end it is always
-implementor's choice whether to negotiate private keys by default or
-whether to use the keys generated by the servers.
+messages, private messages and channel messages.
+
+It is important to note that SILC, like any other security protocol is
+not full proof system and cannot secure from insecure environment; the
+SILC servers and routers could very well be compromised. However, to
+provide acceptable level of security and usability for end user the
+protocol use many times session keys or other keys generated by the
+servers to secure the messages. This is intentional design feature to
+allow ease of use for end user. This way the network is still usable,
+and remains encrypted even if the external means of distributing the
+keys is not working. The implementation, however, may like to not
+follow this design feature, and always negotiate the keys outside SILC
+network. This is acceptable solution and many times recommended. The
+implementation still must be able to work with the server generated keys.
+
+If this is unacceptable for the client or end user, the private keys
+negotiatied outside the SILC Network should always be used. In the end
+it is always implementor's choice whether to negotiate private keys by
+default or whether to use the keys generated by the servers.
It is also recommended that router operators in the SILC Network would
form a joint forum to discuss the router and SILC Network management
Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
.ti 0
7 Author's Address
EMail: priikone@silcnet.org
-This Internet-Draft expires XXX
+This Internet-Draft expires 13 Nay 2002
projects / silc.git / blobdiff