2.3.14 Command Reply Payload .............................. 29
2.3.15 Connection Auth Request Payload .................... 29
2.3.16 New ID Payload ..................................... 30
- 2.3.17 New ID List Payload ................................ 31
- 2.3.18 New Client Payload ................................. 31
- 2.3.19 New Server Payload ................................. 32
- 2.3.20 New Channel Payload ................................ 33
- 2.3.21 New Channel User Payload ........................... 34
- 2.3.22 New Channel List Payload ........................... 35
- 2.3.23 New Channel User List Payload ...................... 36
- 2.3.24 Replace ID Payload ................................. 36
- 2.3.25 Remove ID Payload .................................. 37
- 2.3.26 Remove Channel User Payload ........................ 38
+ 2.3.17 New Client Payload ................................. 31
+ 2.3.18 New Server Payload ................................. 32
+ 2.3.19 New Channel Payload ................................ 33
2.4 SILC ID Types ............................................. 39
2.5 Packet Encryption And Decryption .......................... 39
2.5.1 Normal Packet Encryption And Decryption ............. 39
2.9 Packet Sending ............................................ 43
2.10 Packet Reception ......................................... 43
2.11 Packet Routing ........................................... 44
- 2.12 Packet Forwarding ........................................ 44
- 2.13 Packet Broadcasting ...................................... 45
- 2.14 Packet Tunneling ......................................... 45
+ 2.12 Packet Broadcasting ...................................... 45
+ 2.13 Packet Tunneling ......................................... 45
3 Security Considerations ....................................... 46
4 References .................................................... 46
5 Author's Address .............................................. 47
Figure 17: New Client Payload
Figure 18: New Server Payload
Figure 19: New Channel Payload
-Figure 20: New Channel User Payload
-Figure 21: Replace ID Payload
-Figure 22: Remove Channel User Payload
.ti 0
Encryption And Decryption for more information.
- Forwarded 0x02
+ List 0x02
- Marks the packet to be forwarded. Some specific
- packet types may be forwarded. Receiver of packet
- with this flag set must not forward the packet any
- further. See section 2.12 Packet Forwarding for
- description of packet forwarding.
+ Indicates that the packet consists of list of
+ packet payloads indicated by the Packet Type field.
+ The payloads are added one after the other. Note that
+ there are packet types that must not be used as
+ list. Parsing of list packet is done by calculating
+ the length of each payload and parsing them one by
+ one.
Broadcast 0x04
the disconnection is sent inside the packet payload. Client
usually does not send this packet.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.3 Disconnect Payload
This packet is sent upon successful execution of some protocol.
The status of the success is sent in the packet.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.4 Success Payload
This packet is sent upon failure of some protocol. The status
of the failure is sent in the packet.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.5 Failure Payload
This packet may be sent upon rejection of some protocol.
The status of the rejection is sent in the packet.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.6 Reject Payload
most likely to take action anyway. This packet may be sent
to entity that is indirectly connected to the sender.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.8 Error Payload.
by channel specific keys. Channel Keys are distributed by
SILC_PACKET_CHANNEL_KEY packet.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.9 Channel Message
Payload
may send this packet. This packet may be sent to entity
that is indirectly connected to the sender.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.10 Channel Key Payload
used as well if both of the client knows it, however, it needs
to be agreed outside SILC. See more of this in [SILC1].
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.11 Private Message
Payload
default or to use normal session keys by default, is
implementation specific issue. See more of this in [SILC1].
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.12 Private Message
Key Payload
This packet may be sent to entity that is indirectly connected
to the sender.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.13 Command Payload
The contents of this packet is command specific. This packet
maybe sent to entity that is indirectly connected to the sender.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.14 Command Reply
Payload and section 2.3.13 Command
Payload
This packet is used to start SILC Key Exchange Protocol,
described in detail in [SILC3].
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: Payload of this packet is described
in the section SILC Key Exchange
Protocol and its sub sections in
This packet is used as part of the SILC Key Exchange Protocol.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: Payload of this packet is described
in the section SILC Key Exchange
Protocol and its sub sections in
This packet is used as part of the SILC Key Exchange Protocol.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: Payload of this packet is described
in the section SILC Key Exchange
Protocol and its sub sections in
The party receiving this payload must respond with the same
packet including the mandatory authentication method.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: See section 2.3.15 Connection Auth
Request Payload
the connecting party. The protocol is described in detail in
[SILC3].
+ This packet must not be sent as list and the List flag must
+ not be set.
+
Payload of the packet: Payload of this packet is described
in the section SILC Authentication
Protocol and it sub sections in [SILC].
Payload of the packet: See section 2.3.16 New ID Payload
- 19 SILC_PACKET_NEW_ID_LIST
-
- This packet is used to distribute list of new ID's from
- server to routers. This is equivalent to previous packet
- type except that it may include several ID's. Client must
- not send this packet.
-
- Payload of the packet: See section 2.3.17 New ID List
- Payload
+ 19 SILC_PACKET_NEW_CLIENT
-
- 20 SILC_PACKET_NEW_CLIENT
-
- This packet is used by client to register itself to the
- SILC network. This is sent after key exchange and
+ This packet is used by client to register itself to the
+ SILC network. This is sent after key exchange and
authentication protocols has been completed. Client sends
various information about itself in this packet.
- Payload of the packet: See section 2.3.18 New Client Payload
+ This packet must not be sent as list and the List flag must
+ not be set.
+ Payload of the packet: See section 2.3.19 New Client Payload
- 21 SILC_PACKET_NEW_SERVER
+
+ 20 SILC_PACKET_NEW_SERVER
This packet is used by server to register itself to the
SILC network. This is sent after key exchange and
its Server ID and other information in this packet.
Client must not send or receive this packet.
- Payload of the packet: See section 2.3.19 New Server Payload
+ This packet must not be sent as list and the List flag must
+ not be set.
+
+ Payload of the packet: See section 2.3.20 New Server Payload
- 22 SILC_PACKET_NEW_CHANNEL
+ 21 SILC_PACKET_NEW_CHANNEL
This packet is used to notify routers about newly created
channel. Channels are always created by the router and it must
packet. This packet maybe sent to entity that is indirectly
connected to the sender.
- Payload of the packet: See section 2.3.20 New Channel Payload
-
-
- 23 SILC_PACKET_NEW_CHANNEL_USER
-
- This packet is used to notify routers about new user on channel.
- The packet is sent after user has joined to the channel. Server
- may send this packet to its router and router may send this to
- its primary router. Client must not send this packet. This
- packet maybe sent to entity that is indirectly connected to
- the sender.
-
- When received, the server or router must distribute
- SILC_NOTIFY_TYPE_JOIN to local clients on the channel.
-
- Payload of the packet: See section 2.3.21 New Channel User
- Payload
-
-
- 24 SILC_PACKET_NEW_CHANNEL_LIST
-
- This packet is used to distribute list of created channels
- from server to routers. This is equivalent to the packet
- SILC_PACKET_NEW_CHANNEL except that it may include several
- payloads. Client must not send this packet.
-
- Payload of the packet: See section 2.3.22 New Channel List
- Payload
-
-
- 25 SILC_PACKET_NEW_CHANNEL_USER_LIST
-
- This packet is used to distribute list of users on specific
- channel from server to routers. This is equivalent to the
- packet SILC_PACKET_NEW_CHANNEL_USER except that it may
- include several payloads. Client must not send this packet.
-
- When received, the server or router must distribute
- SILC_NOTIFY_TYPE_JOIN to local clients on the channel.
-
- Payload of the packet: See section 2.3.23 New Channel User
- List Payload
-
-
- 26 SILC_PACKET_REPLACE_ID
-
- This packet is used to replace old ID with new ID sent in
- the packet payload. For example, when client changes its
- nickname new ID is created and this packet can be used to
- distribute the new ID and the old ID is removed when it is
- send in the packet. Client cannot send or receive this
- packet. This packet maybe sent to entity that is indirectly
- connected to the sender.
-
- When received and the replaced ID is Client ID the server or
- router must distribute SILC_NOTIFY_TYPE_NICK_CHANGE to the
- local clients on the channels (if any) of the client whose
- ID was changed. However, the notify type must be sent only
- once per client.
-
- Payload of the packet: See section 2.3.24 Replace ID Payload
-
-
- 27 SILC_PACKET_REMOVE_ID
-
- This packet is used to removed ID. For example, when client
- exits SILC network its ID is removed. Client must not send
- this packet. This packet maybe sent to entity that is
- indirectly connected to the sender.
-
- When received and the replaced ID is Client ID the server or
- router must distribute SILC_NOTIFY_TYPE_SIGNOFF to the
- local clients on the channels (if any) of the client whose
- ID was changed. However, the notify type must be sent only
- once per client.
-
- Payload of the packet: See section 2.3.25 Remove ID Payload
-
-
- 28 SILC_PACKET_REMOVE_CHANNEL_USER
-
- This packet is used to remove user from a channel. This is
- used by router to notify other routers in the network that a
- client has left a channel. This packet maybe sent to entity
- that is indirectly connected to the sender.
-
- When received, the server or router must distribute
- SILC_NOTIFY_TYPE_LEAVEW to local clients on the channel.
-
- Payload of the packet: See section 2.3.26 Remove Channel User
- Payload
+ Payload of the packet: See section 2.3.21 New Channel Payload
- 29 SILC_PACKET_REKEY
+ 22 SILC_PACKET_REKEY
This packet is used to indicate that re-key must be performed
for session keys. See section Session Key Regeneration in
[SILC1] for more information. This packet does not have
a payload.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
- 30 SILC_PACKET_REKEY_DONE
+ 23 SILC_PACKET_REKEY_DONE
This packet is used to indicate that re-key is performed and
new keys must be used hereafter. This is sent only if re-key
as SILC Key Exchange protocol is executed. This packet does
not have a payload.
+ This packet must not be sent as list and the List flag must
+ not be set.
+
+
+ 24 SILC_PACKET_HEARTBEAT
+
+ This packet is used by clients, servers and routers to keep the
+ connection alive. It is recommended that all servers implement
+ keepalive actions and perform it to both direction in a link.
+ This packet does not have a payload.
- 31 - 199
+ This packet must not be sent as list and the List flag must
+ not be set.
+
+
+ 25 - 199
Currently undefined commands.
sent from server to client, however, server may send it to another
server as well. This payload may also be sent to a channel. Client must
not send this payload. The receiver of this payload may totally ignore the
-contents of the payload, however, notify message should be noted and
-possibly logged.
+contents of the payload, however, notify message should be audited.
The payload may only be sent with SILC_PACKET_NOTIFY packet. It must
not be sent in any other packet type. Following diagram represents the
Sent when client has joined to a channel. The server must distribute
this type only to the local clients on the channel and then send
- SILC_PACKET_NEW_CHANNEL_USER packet to its primary route. The router
- or server receiving the packet distributes this type to the local
- clients on the channel. See description of SILC_PACKET_NEW_CHANNEL_USER
- packet for more information.
+ it to its primary router. The router or server receiving the packet
+ distributes this type to the local clients on the channel and
+ broadcast it to the network.
- Max Arguments: 1
- Arguments: (1) <Client ID>
+ Max Arguments: 2
+ Arguments: (1) <Client ID> (2) <Channel ID>
- The <Client ID> is the client that joined to the channel.
+ The <Client ID> is the client that joined to the channel indicated
+ by the <Channel ID>.
3 SILC_NOTIFY_TYPE_LEAVE
Sent when client has left a channel. The server must distribute
this type only to the local clients on the channel and then send
- SILC_PACKET_REMOVE_CHANNEL_USER packet to its primary route. The
- router or server receiving the packet distributes this type to the
- local clients on the channel. See description of
- SILC_PACKET_REMOVE_CHANNEL_USER packet for more information.
+ it to its primary router. The router or server receiving the packet
+ distributes this type to the local clients on the channel and
+ broadcast it to the network.
Max Arguments: 1
Arguments: (1) <Client ID>
4 SILC_NOTIFY_TYPE_SIGNOFF
- Sent when client signoffs from SILC network. This type is sent only
- if the client was joined to any channel. This type is sent by server
- or router when SILC_PACKET_REMOVE_ID packet has been received. See
- detailed information from description of SILC_PACKET_REMOVE_ID packet.
+ Sent when client signoffs from SILC network. The server must
+ distribute this type only to the local clients on the channel and
+ then send it to its primary router. The router or server receiving
+ the packet distributes this type to the local clients on the channel
+ and broadcast it to the network.
- Max Arguments: 1
- Arguments: (1) <Client ID>
+ Max Arguments: 2
+ Arguments: (1) <Client ID> (2) <message>
- The <Client ID> is the client who left SILC network.
+ The <Client ID> is the client who left SILC network. The <message>
+ is free text string indicating the reason of signoff.
5 SILC_NOTIFY_TYPE_TOPIC_SET
6 SILC_NOTIFY_TYPE_NICK_CHANGE
- Sent when client changes nick on a channel. This type is sent only if
- the client has joined to any channel. This type is sent by server or
- router when SILC_PACKET_REPLACE_ID packet has been received. See
- detailed information from description of SILC_PACKET_REPLACE_ID packet.
+ Sent when client changes nick on a channel. The server must
+ distribute this type only to the local clients on the channel and
+ then send it to its primary router. The router or server receiving
+ the packet distributes this type to the local clients on the channel
+ and broadcast it to the network.
Max Arguments: 2
Arguments: (1) <Old Client ID> (2) <New Client ID>
only to the clients who is joined on the channel where the target
client is on.
- Max Arguments: 3
+ Max Arguments: 3
Arguments: (1) <Client ID> (2) <mode mask>
(3) <Target Client ID>
The <Client ID> is the client who changed the mode. The <mode mask>
is the new mode mask of the channel. The <Target Client ID> is the
- client whose mode was changed.
+ client which mode was changed.
9 SILC_NOTIFY_TYPE_MOTD
Arguments: (1) <motd>
The <motd> is the Message of the Day.
+
+
+10 SILC_NOTIFY_TYPE_CHANNEL_CHANGE
+
+ Sent when channel's ID has changed for a reason or another. This
+ is sent by noral server to the client. Client must change the
+ old Channel ID to the new one. This type must be sent only to the
+ clients who is joined on the channel.
+
+ Max Arguments: 2
+ Arguments: (1) <Old Channel ID> (2) <New Channel ID>
+
+ The <Old Channel ID> is the channel's old ID and the <New Channel ID>
+ is the new one that must replace the old one.
+
+
+11 SILC_NOTIFY_TYPE_SERVER_SIGNOFF
+
+ Sent when server quits SILC network. Those clients from this server
+ that are on channels must be removed from the channel.
+
+ Max Arguments: 1
+ Arguments: (1) <Server ID>
+
+ The <Server ID> is the server's ID.
+
.in 3
Notify types starting from 16384 are reserved for private notify
the client. After that, client starts using the key received
in this payload to protect the traffic on the channel.
+The client who is joining to the channel receives its key in the
+SILC_COMMAND_JOIN command reply message thus it is not necessary to
+send this payload to the entity who sent the SILC_COMMAND_JOIN command.
+
Channel keys are cell specific thus every router in cell have
to create a channel key and distribute it if any client in the
cell has joined to a channel. Channel traffic between cell's
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | SILC Command | Arguments Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Command Unifier |
+| Command Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
payload including any command argument payloads associated
with this payload.
-o SILC Command (1 byte) - SILC Command identifier. This must
+o SILC Command (1 byte) - Indicates the SILC command. This must
be set to non-zero value. If zero (0) value is found in this
field the packet must be discarded.
command payload. See section 2.3.2.2 for definition of the
Argument Payload.
-o Command Unifier (2 bytes) - Unifies this command at the
+o Command Identifier (2 bytes) - Identifies this command at the
sender's end. The entity who replies to this command must
set the value found from this field into the Command Payload
used to send the reply to the sender. This way the sender
can identify which command reply belongs to which originally
sent command. What this field includes is implementation
issue but it is recommended that wrapping counter value is
- used in the field.
+ used in the field. Value zero (0) in this field means that
+ no specific value is set.
.in 3
See [SILC1] for detailed description of different SILC commands,
SILC_PACKET_NEW_SERVER to the router it connected to. The case is same
when router connects to another router.
+However, this payload is not and must not be used to send information
+about new channels. New channels are always distributed by sending the
+dedicated SILC_PACKET_NEW_CHANNEL packet.
+
Hence, this payload is very important and used every time when some
new entity is registered to the SILC network. Client never sends this
payload. Both client and server (and router) may receive this payload.
2.3.2.1 for generic ID Payload.
-.ti 0
-2.3.17 New ID List Payload
-
-New ID List Payload is used to distribute list of ID's usually from
-server to router but also from router to other routers in the network.
-This payload is used, for example, when server is connected to router
-and the server wants to distribute all of its locally connected clients
-and locally created channels to the router. It is convenient in this
-case to use this payload instead of sending all the information one
-by one using New ID Payload.
-
-There is no specific payload for this packet type. The packet type
-uses same payload as described in previous section. To form a list
-several payloads is put in the packet each after each. The payload
-is variable in length but can be calculated by calculating the ID
-Type field, Length field and the ID Data fields together. This forms
-one New ID Payload in the list.
-
-The list of payloads may only be sent with SILC_PACKET_NEW_ID_LIST
-packet. They must not be sent in any other packet type.
-
-
.ti 0
2.3.18 New Client Payload
in the SILC network by sending this packet payload. Channels are
created by router of the cell. Server never creates channels unless
it is a standalone server and it does not have router connection,
-in this case server acts as router. Normal server forwards JOIN command
+in this case server acts as router. Normal server send JOIN command
to the router (after it has received JOIN command from client) which
then processes the command and creates the channel. Client never sends
this packet.
.in 3
-.ti 0
-2.3.21 New Channel User Payload
-
-When client (user) joins to a channel, server must notify routers
-about the new user on the channel. Normal server sends this packet
-payload to its router which then broadcasts the packet further.
-Router sends this packet always to its primary router. Client must
-not send this packet payload. The mode of the user is NONE after
-user has joined to the channel.
-
-The payload may only be sent with SILC_PACKET_NEW_CHANNEL_USER
-packet. It must not be sent in any other packet type. Following
-diagram represents the New Channel User 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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Channel ID Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Channel ID ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Client ID Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Client ID ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 20: New Channel User Payload
-
-
-.in 6
-o Channel ID Length (2 bytes) - Length of the Channel ID.
-
-o Channel ID (variable length) - The Channel ID of the channel
- to which the client has joined.
-
-o Client ID Length (2 bytes) - Length of the Client ID.
-
-o Client ID (variable length) - The Client ID of the client
- who has joined the channel.
-.in 3
-
-
-.ti 0
-2.3.22 New Channel List Payload
-
-This payload is used to distribute list of new channels from server
-to routers. It might convenient to send list of new channels when
-existing server connects to router, instead of sending them one
-by one.
-
-There is no specific payload for this packet type. The packet type
-uses same payload as described in 2.3.19 New Channel Payload. To form
-a list several payloads is put in the packet each after each. The
-payload is variable in length but can be calculated by calculating
-the length of the fields together. This forms one New Channel Payload
-in the list.
-
-The list of payloads may only be sent with SILC_PACKET_NEW_CHANNEL_LIST
-packet. They must not be sent in any other packet type.
-
-
-.ti 0
-2.3.23 New Channel User List Payload
-
-This payload is used to distribute list of channel users on specific
-channel from server to routers. It might convenient to send list of
-channel users when existing server connects to router, instead of
-sending them one by one.
-
-There is no specific payload for this packet type. The packet type
-uses same payload as described in 2.3.20 New Channel User Payload.
-To form a list several payloads is put in the packet each after each.
-The payload is variable in length but can be calculated by calculating
-the length of the fields together. This forms one New Channel User
-Payload in the list.
-
-The list of payloads may only be sent with packet
-SILC_PACKET_NEW_CHANNEL_USER_LIST. They must not be sent in any other
-packet type.
-
-
-.ti 0
-2.3.24 Replace ID Payload
-
-This payload is used to replace old ID with new ID sent in the payload.
-When ID changes for some entity and the new ID is wanted to replace the
-old one this payload must be used. Client cannot send or receive this
-payload. Normal server and router server may send and receive this
-payload. After this packet has been sent the old ID must not be used
-anymore.
-
-The payload may only be sent with SILC_PACKET_REPLACE_ID packet. It must
-not be sent in any other packet type. Following diagram represents the
-Replace Payload 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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Old ID Type | Old ID Length |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ Old ID Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| New ID Type | New ID Length |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ New ID Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 21: Replace ID Payload
-
-
-.in 6
-o Old ID Type (2 bytes) - Indicates the type of the old ID. See
- section 2.4 SILC ID Types for list of defined ID types.
-
-o Old ID Length (2 bytes) - Length of the old ID Data area not
- including the length of any other fields in the payload.
-
-o Old ID Data (variable length) - The actual old ID data.
-
-o New ID Type (2 bytes) - Indicates the type of the new ID. See
- section 2.4 SILC ID Types for list of defined ID types.
-
-o New ID Length (2 bytes) - Length of the new ID Data area not
- including the length of any other fields in the payload.
-
-o New ID Data (variable length) - The actual new ID data.
-.in 3
-
-
-.ti 0
-2.3.25 Remove ID Payload
-
-Remove ID payload is used to remove ID from SILC network. This is used
-for example when client exits SILC network. The server must in this
-case send this payload to notify that this ID is not valid anymore.
-After this has been send the old ID must not be used anymore. Client
-must not send this payload.
-
-The packet uses generic ID Payload as New ID Payload. See section
-2.3.2.1 for generic ID Payload.
-
-
-.ti 0
-2.3.26 Remove Channel User Payload
-
-Remove Channel User payload is used to remove a user from a channel network
-wide. This is used by routers to notify other routers that a user has
-left a channel. As routers keep information about users on channels a
-user leaving channel must be removed from all routers. Normal server may
-send this payload as well. Client must not send this payload.
-
-The payload may only be sent with SILC_PACKET_REMOVE_CHANNEL USER packet.
-It must not be sent in any other packet type. Following diagram
-represents the Remove Payload 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 Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Channel ID Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Channel ID Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 22: Remove Channel User Payload
-
-
-.in 6
-o Client ID Length (2 bytes) - Length of the Client ID Data area
- not including the length of any other fields in the payload.
-
-o Client ID Data (variable length) - The Client ID of the user
- that has left the channel.
-
-o Channel ID Length (2 bytes) - Length of the Channel ID Data area
- not including the length of any other fields in the payload.
-
-o Channel ID Data (variable length) - The Channel ID of the channel
- the user has left.
-.in 3
-
-
-
.ti 0
2.4 SILC ID Types
.ti 0
-2.12 Packet Forwarding
-
-Currently SILC command packets may be forwarded from one entity to another.
-Any other packet currently cannot be forwarded but support for more packet
-types may be added if needed. Forwarding is usually used by server to
-forward some command request coming from client to the router as the server
-may be incapable to handle the request. Forwarding may be only one hop
-long; the receiver of the packet with Forwarded flag set in the SILC
-Packet header must not forward the packet any further.
-
-The normal scenario is that client sends JOIN command to the server which
-is not able to create the channel as there are no local clients on the
-channel. Channels are created always by the router of the cell thus the
-packet must be forwarded to the router. The server forwards the original
-packet coming from client to the router after it has set the Forwarded
-flag to the SILC Packet header.
-
-Router receiving the packet knows that the packet has to be processed
-specially by checking the flags and the Forwarded flag in the SILC Packet
-header. After router has joined the client to the channel (and perhaps
-created a new channel) it sends normal command reply packet to the
-client. However, as the router doesn't have direct connection to the
-client the packet is sent through the server. Server detects that
-the command reply packet is destined to the client and sends it to
-the client.
-
-
-.ti 0
-2.13 Packet Broadcasting
+2.12 Packet Broadcasting
SILC packets may be broadcasted in SILC network. However, only router
server may send or receive broadcast packets. Client and normal server
.ti 0
-2.14 Packet Tunneling
+2.13 Packet Tunneling
Tunneling is a feature that is available in SILC protocol. Tunneling
means that extra SILC Packet Header is applied to the original packet
3 Security Considerations
Security is central to the design of this protocol, and these security
-considerations permeate the specification.
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
.ti 0
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
Internet Draft.
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
-
-
-
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
.ti 0
projects / silc.git / blobdiff