Figure 7: Disconnect Payload
Figure 8: Success Payload
Figure 9: Failure Payload
-Figure 10: Reject Payload
+Figure 10: Reject Payload
Figure 11: Notify Payload
Figure 12: Error Payload
Figure 13: Channel Message Payload
The following list of currently defined notify types. The format for
notify arguments is same as in SILC commands described in [SILC4].
-Also, all ID's sent in arguments are sent inside ID Payload.
+Note that all ID's sent in arguments are sent inside ID Payload. Also
+note that all passphrases that may be sent inside arguments MUST be
+UTF-8 [RFC2279] encoded.
.in 6
0 SILC_NOTIFY_TYPE_NONE
topic was set or changed.
Max Arguments: 2
- Arguments: (1) <Client ID> (2) <topic>
+ Arguments: (1) <ID Payload> (2) <topic>
- The <Client ID> is the client which set or changed the <topic>.
+ The <ID Payload> is the ID of the entity who set the topic. It
+ usually is Client ID but it can be Server ID and Channel ID as well.
6 SILC_NOTIFY_TYPE_NICK_CHANGE
receiving the packet distributes this type to the local clients
on the channel and broadcast it to the network.
- Max Arguments: 2
+ Max Arguments: 3
Arguments: (1) <Old Client ID> (2) <New Client ID>
+ (3) <nickname>
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 change of the nickname. The <nickname> is the new nickname.
7 SILC_NOTIFY_TYPE_CMODE_CHANGE
to the clients which is joined on the channel which mode was
changed.
- Max Arguments: 4
- Arguments: (1) <ID Payload> (2) <mode mask>
- (3) [<cipher>] (4) <[hmac>]
+ Max Arguments: 5
+ Arguments: (1) <ID Payload> (2) <mode mask>
+ (3) [<cipher>] (4) <[hmac>]
+ (5) [<passphrase>]
The <ID Payload> is the ID (usually Client ID but it can be
Server ID as well when the router is enforcing channel mode
ignore the <cipher> argument since the SILC_PACKET_CHANNEL_KEY
packet will force the new channel key change anyway. The <hmac>
argument is important since the client is responsible of setting
- the new HMAC and the hmac key into use.
+ the new HMAC and the hmac key into use. The <passphrase> is
+ the passphrase of the channel, if it was now set.
8 SILC_NOTIFY_TYPE_CUMODE_CHANGE
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) <Client ID> (2) [<comment>]
+ Max Arguments: 3
+ Arguments: (1) <Client ID> (2) [<comment>]
+ (3) <Killer's Client 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 killing. The <Killer's Client ID> is the killer.
14 SILC_NOTIFY_TYPE_UMODE_CHANGE
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Flags | Message Length |
+| Message Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Data ~
.in 6
-o Flags (2 bytes) - Includes the flags of the channel
- messages. The flags can indicate a reason or purpose
- for the channel message. Note that the Private Message
- Payload use these same flags for the same purpose. The
- following flags are defined:
+o Message Flags (2 bytes) - Includes the Message Flags of
+ the channel messages. The flags can indicate a reason or
+ purpose for the channel message. Note that the Private
+ Message Payload use these same Message Flags for the same
+ purpose. The following Message Flags are defined:
0x0000 SILC_MESSAGE_FLAG_NONE
of the signing process and any associated payloads
of this flag.
- 0x0040 - 0x0200 RESERVED
+ 0x0040 SILC_MESSAGE_FLAG_REPLY
+
+ This is a generic reply flag to send a reply to
+ previously received request. A separate document
+ should define any payloads associated to this flag.
+
+ 0x0080 SILC_MESSAGE_FLAG_DATA
+
+ This is a generic data flag, indicating that the
+ message includes some data which can be interpreted
+ in a specific way. Using this flag any kind of data
+ can be delivered inside message payload. A separate
+ document should define how this flag is interpreted
+ and define any associated payloads.
+
+ 0x0100 - 0x0800 RESERVED
Reserved for future flags
- 0x0400 - 0x8000 PRIVATE RANGE
+ 0x1000 - 0x8000 PRIVATE RANGE
Private range for free use.
other parts of the packet.
o MAC (variable length) - The MAC computed from the
- Message Length, Message Data, Padding Length and Padding
- fields. This protects the integrity of the plaintext
- channel message. The receiver can verify from the MAC
- whether the message decrypted correctly. Also, if more than
- one private key has been set for the channel, the receiver
- can verify which of the keys decrypted the message
+ Message Length, Message Data, Padding Length, Padding and
+ Initial Vector fields. This protects the integrity of the
+ plaintext channel message. The receiver can verify from
+ the MAC whether the message decrypted correctly. Also, if
+ more than one private key has been set for the channel, the
+ receiver can verify which of the keys decrypted the message
correctly. Note that, this field is encrypted and MUST
be added to the padding calculation.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Flags | Message Data Length |
+| Message Flags | Message Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Data ~
.in 6
-o Flags (2 bytes) - This field includes the flags of the
- private message. They can indicate a different reason or
- purpose for the private message. See the section 2.3.9
- Channel Message Payload for defined flags. Note that
+o Message Flags (2 bytes) - This field includes the Message
+ Flags of the private message. They can indicate a different
+ reason or purpose for the private message. See the section
+ 2.3.9 Channel Message Payload for defined flags. Note that
the Channel Message Payload use the same flags for the
same purpose.
.ti 0
2.3.12 Private Message Key Payload
-This payload is used to send key from client to another client that
-is going to be used to protect the private messages between these
-two clients. If this payload is not sent normal session key
-established by the SILC Key Exchange Protocol is used to protect
-the private messages.
+This payload is optional and can be used to send private message
+key between two clients in the network. The packet is secured with
+normal session keys. By default private messages are encrypted
+with session keys, and with this payload it is possible to set
+private key for private message encryption between two clients.
+
+The receiver of this payload SHOULD verify for example from user
+whether user wants to receive private message key. Note that there
+are other, more secure ways of exchanging private message keys in
+the SILC network. Instead of sending this payload it is possible to
+negotiate the private message key with SKE protocol using the Key
+Agreement payload directly peer to peer.
This payload may only be sent by client to another client. Server
MUST NOT send this payload at any time. After sending this payload
Routers form a ring in the SILC network. However, routers may have other
direct connections to other routers in the network too. This can cause
interesting routing problems in the network. Since the network is a ring,
-the packets usually should be routed into counter clock-wise direction,
-or if it cannot be used then always clock-wise (primary route) direction.
+the packets usually should be routed into clock-wise direction, or if it
+cannot be used then always counter clock-wise (primary route) direction.
Problems may arise when a faster direct route exists and router is routing
a channel message. Currently channel messages must be routed either
in upstream or downstream, they cannot be routed to other direct routes.
[SFTP] Ylonen T., and Lehtinen S., "Secure Shell File Transfer
Protocol", Internet Draft, March 2001.
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
.ti 0
5 Author's Address
70100 Kuopio
Finland
-EMail: priikone@silcnet.org
+EMail: priikone@iki.fi
This Internet-Draft expires XXX
projects / silc.git / blobdiff