2.3.20 Key Agreement Payload .............................. 43
2.3.21 Resume Router Payload .............................. 44
2.3.22 File Transfer Payload .............................. 44
+ 2.3.23 Resume Client Payload .............................. XXXXXX
2.4 SILC ID Types ............................................. 46
2.5 Packet Encryption And Decryption .......................... 46
2.5.1 Normal Packet Encryption And Decryption ............. 46
Figure 21: Key Agreement Payload
Figure 22: Resume Router Payload
Figure 23: File Transfer Payload
+Figure 24: Resume Client Payload
.ti 0
Payload of the packet: See section 2.3.22 File Transfer Payload
- 28 - 199
+ 28 SILC_PACKET_RESUME_CLIENT
+
+ This packet is used to resume a client back to the network
+ after it has been detached. A client is able to detach from
+ the network but the client is still valid client in the network.
+ The client may then later resume its session back by sending
+ this packet to a server. Routers also use this packet to notify
+ other routers in the network that the detached client has resumed.
+
+ This packet MUST NOT be sent as list and the List flag MUST
+ NOT be set.
+
+ Payload of the packet: See section 2.3.23 Resume Client Payload
+
+
+ 29 - 199
Currently undefined commands.
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
The <Old Client ID> is the old ID of the client which changed
the nickname. The <New Client ID> is the new ID generated by
the change of the nickname. The <nickname> is the new nickname.
+ Note that it is possible to send this notify even if the nickname
+ hasn't changed, but client ID has changed.
7 SILC_NOTIFY_TYPE_CMODE_CHANGE
Max Arguments: 3
Arguments: (1) <Client ID> (2) [<comment>]
- (3) <Killer's Client ID>
+ (3) <Killer's ID>
The <Client ID> is the client which was killed from the network.
The killer may have set the <comment> to indicate the reason for
- the killing. The <Killer's Client ID> is the killer.
+ the killing. The <Killer's ID> is the killer, which may be
+ client but also router server.
14 SILC_NOTIFY_TYPE_UMODE_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
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 payload may only be sent with SILC_PACKET_FTP packet. It MUST NOT
be sent in any other packet type. The following diagram represents the
-File Transfer Payload
+File Transfer Payload.
.in 5
.nf
.in 3
+.ti 0
+2.3.23 Resume Client Payload
+
+This payload is used by client to resume its detached session in the
+SILC Network. A client is able to detach itself from the network by
+sending SILC_COMMAND_DETACH command to its server. The network
+connection to the client is lost but the client remains as valid
+client in the network. The client is able to resume the session back
+by sending this packet and including the old Client ID, and an
+Authentication Payload [SILC1] which the server uses to verify with
+the detached client's public key. This also implies that the
+mandatory authentication method is public key authentication.
+
+Server or router that receives this from the client also sends this,
+without the Authentication Payload, to routers in the network so that
+they know the detached client has resumed. Refer to the [SILC1] for
+detailed description how the detaching and resuming prodecure is
+performed.
+
+The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the Resume Client Payload.
+
+.in 5
+.nf
+ 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Client ID Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Client ID ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Authentication Payload ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 24: Resume Client Payload
+
+
+.in 6
+o Client ID Length (1 byte) - The length of the Client ID
+ field not including any other field.
+
+o Client ID (variable length) - The detached client's Client
+ ID. The client that sends this payload must know the Client
+ ID.
+
+o Authentication Payload (variable length) - The authentication
+ payload that the server will verify with the detached client's
+ public key. If the server doesn't know the public key, it must
+ retrieve it for example with SILC_COMMAND_GETKEY command.
+.in 3
+
.ti 0