.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 27 June 2000
-.ds CH SILC Packet Protocol
+.ds RH 13 September 2000
+.ds CH
.na
.hy 0
.in 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-pp-00.txt 27 June 2000
-Expires: 27 Jan 2001
+draft-riikonen-silc-pp-00.txt 13 September 2000
+Expires: 13 May 2001
.in 3
-.ce
+.ce 2
SILC Packet Protocol
+<draft-riikonen-silc-pp-00.txt>
.ti 0
Status of this Memo
-This document is an Internet-Draft. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas,
-and its working groups. Note that other groups may also distribute
-working documents as Internet-Drafts.
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026. Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups. Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time. It is inappropriate to use Internet-Drafts
-as reference material or to cite them other than as
-``work in progress.''
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
-To learn the current status of any Internet-Draft, please check the
-``1id-abstracts.txt'' listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-ftp.isi.edu (US West Coast).
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
-The distribution of this memo is unlimited.
+The distribution of this memo is unlimited.
.ti 0
2.8 Packet Compression ........................................ 40
2.9 Packet Sending ............................................ 40
2.10 Packet Reception ......................................... 41
- 2.11 Packet Broadcasting ...................................... 41
- 2.12 Packet Routing ........................................... 42
- 2.13 Packet Tunneling ......................................... 42
+ 2.11 Packet Routing ........................................... 42
+ 2.12 Packet Forwarding ........................................
+ 2.13 Packet Broadcasting ...................................... 41
+ 2.14 Packet Tunneling ......................................... 42
3 Security Considerations ....................................... 43
4 References .................................................... 43
5 Author's Address .............................................. 44
Figure 20: New Channel User Payload
Figure 21: Replace ID Payload
Figure 22: Remove ID Payload
+Figure 23: Remove Channel User Payload
.ti 0
Encryption And Decryption for more information.
- Broadcast 0x02
+ Forwarded 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
+ desribtion of packet forwarding.
+
+
+ Broadcast 0x04
Marks the packet to be broadcasted. Client cannot
send broadcast packet and normal server cannot send
set must send (broadcast) the packet to its primary
route. If router has several router connections the
packet may be sent only to the primary route. See
- section 2.11 Packet Broadcasting for description of
+ section 2.13 Packet Broadcasting for description of
packet broadcasting.
- Tunneled 0x04
+ Tunneled 0x08
Marks that the packet is tunneled. Tunneling means
that extra SILC Packet Header has been applied to the
original packet. The outer header has this flag
- set. See section 2.13 Packet Tunneling for more
+ set. See section 2.14 Packet Tunneling for more
information.
.in 3
This packet is sent when an error occurs. Server may
send this packet. Client never sends this packet. The
client may entirely ignore the packet, however, server is
- most likely to take action anyway.
+ most likely to take action anyway. This packet may be sent
+ to entity that is indirectly connected to the sender.
Payload of the packet: See section 2.3.7 Error Payload.
Payload of the packet: See section 2.3.24 Remove ID Payload
- 28 SILC_PACKET_REKEY
+ 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 leaved a channel. This packet maybe sent to entity
+ that is indirectly connected to the sender.
+
+ Payload of the packet: See section 2.3.25 Remove Channel User
+ Payload
+
+
+ 29 SILC_PACKET_REKEY
This packet is used to indicate that re-key must be performed
for session keys. See section Session Key Regeneration in
a payload.
-
-
- 29 SILC_PACKET_REKEY_DONE
+ 30 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
not have a payload.
- 30 - 254
+ 31 - 254
Currently undefined commands.
This is opposite of Success Payload. Indication of failure of
some protocol is sent in the payload.
+
.in 5
.nf
1 2 3
.in 3
+
+
+
.ti 0
2.3.6 Notify Payload
not be sent in any other packet type. Following diagram represents the
Notify 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Notify Type | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Notify Message ~
| |
.in 6
+o Notify Type (2 bytes) - Indicates the type of the notify
+ message.
+
o Notify Message (variable length) - Human readable notify
message.
.in 3
The SILC header in this packet is encrypted with the session key
of the next receiver of the packet. Nothing else is encrypted
-with that key. Hence, the actual packet and padding to be
+with that key. Thus, the actual packet and padding to be
encrypted with the session key is SILC Header plus padding to it
to make it multiple by eight (8) or multiple by the block size
of the cipher, which ever is larger.
the channel the message is destined to by checking the destination
ID from the SILC Packet header which tells the destination channel.
The original sender of the packet is also determined by checking
-the source ID from the header which tells the who client sent
+the source ID from the header which tells the client who sent
the message.
The payload may only be sent with SILC_PACKET_CHANNEL_MESSAGE packet.
It must not be sent in any other packet type. Following diagram
-represents the Notify Payload.
+represents the Channel Message Payload.
(*) indicates that the field is not encrypted.
The payload may only be sent with SILC_PACKET_PRIVATE_MESSAGE_KEY
packet. It must not be sent in any other packet type. Following
-diagram represents the Private Message Payload.
+diagram represents the Private Message Key Payload.
.in 5
.ti 0
2.3.12 Command Payload
-Command Payload is used to send SILC commands from client to server.
-Following diagram represents the Command Payload.
+Command Payload is used to send SILC commands from client to server.
+Also server may send commands to other servers. Following diagram
+represents the Command Payload.
.in 5
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| SILC Command | Arguments Num | Payload Length |
+| Payload Length | SILC Command | Arguments Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Command Unifier |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3
.ce
.in 6
+o Payload Length (2 bytes) - Length of the entire command
+ payload including any command argument payloads associated
+ with this payload.
+
o SILC Command (1 byte) - SILC Command identifier. This must
be set to non-zero value. If zero (0) value is found in this
field the packet must be discarded.
field is set to zero (0). The arguments must follow the
command payload.
-o Payload Length (2 bytes) - Length of the entire command
- payload including any command argument payloads associated
- with this payload.
+o Command Unifier (2 bytes) - Unifies 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.
.in 3
See [SILC1] for detailed description of different SILC commands,
.ti 0
2.3.13 Command Reply Payload
-Command Reply Payload is used to send replies to the commands sent
-by the client. The Command Reply Payload is identical to the
-Command Payload hence see the upper sections for Command Payload
-and for Command Argument Payload specifications. Command Reply
-message uses the Command Argument Payload as well.
+Command Reply Payload is used to send replies to the commands. The
+Command Reply Payload is identical to the Command Payload thus see the
+upper sections for Command Payload and for Command Argument Payload
+specifications. Command Reply message uses the Command Argument Payload
+as well.
+
+The entity who sends the reply packet must set the Command Unifier
+field in the reply packet's Command Payload to the value it received
+in the original command packet.
See SILC Commands in [SILC1] for detailed description of different
SILC commands, their arguments and their reply messages.
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 sends JOIN command
+in this case server acts as router. Normal server forwards 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.
removed. See section 2.4 SILC ID Types for list of defined
ID types.
-o ID Length (2 bytes) - Length of the D Data area not including
+o ID Length (2 bytes) - Length of the ID Data area not including
the length of any other fields in the payload.
o ID Data (variable length) - The actual ID data to be removed.
.in 3
+.ti 0
+2.3.25 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
+leaved 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 23: 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
The sender of the packet must assemble the SILC Packet Header with
correct values. It must set the Source ID of the header as its own
-ID. It must also set the Destination ID of the header to the true
-destination. If the destination is client it will be Client ID, if
-it is server it will be Server ID and if it is channel it will be
-Channel ID.
+ID, unless it is forwarding the packet. It must also set the Destination
+ID of the header to the true destination. If the destination is client
+it will be Client ID, if it is server it will be Server ID and if it is
+channel it will be Channel ID.
If the sender wants to compress the packet it must apply the
compression now. Sender must also compute the padding as described
.ti 0
-2.11 Packet Broadcasting
-
-SILC packets may be broadcasted in SILC network. However, only router
-server may send or receive broadcast packets. Client and normal server
-must not send broadcast packets and they must ignore broadcast packets
-if they receive them. Broadcast packets are sent by setting Broadcast
-flag to the SILC packet header.
-
-Broadcasting packets means that the packet is sent to all routers in
-the SILC network, except to the router that sent the packet. The router
-receiving broadcast packet must send the packet to its primary route.
-The fact that SILC routers may have several router connections may
-cause problems, such as race conditions inside the SILC network, if
-care is not taken when broadcasting packets. Router must not send
-the broadcast packet to any other route except to its primary route.
-
-If the primary route of the router is the original sender of the packet
-the packet must not be sent to the primary route. This may happen
-if router has several router connections and some other router uses
-the router as its primary route.
-
-Routers use broadcast packets to broadcast for example information
-about newly registered clients, servers, channels etc. so that all the
-routers may keep these informations up to date.
-
-
-.ti 0
-2.12 Packet Routing
+2.11 Packet Routing
Routers are the primary entities in the SILC network that takes care
of packet routing. However, normal servers routes packets as well, for
.ti 0
-2.13 Packet Tunneling
+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
+
+SILC packets may be broadcasted in SILC network. However, only router
+server may send or receive broadcast packets. Client and normal server
+must not send broadcast packets and they must ignore broadcast packets
+if they receive them. Broadcast packets are sent by setting Broadcast
+flag to the SILC packet header.
+
+Broadcasting packets means that the packet is sent to all routers in
+the SILC network, except to the router that sent the packet. The router
+receiving broadcast packet must send the packet to its primary route.
+The fact that SILC routers may have several router connections may
+cause problems, such as race conditions inside the SILC network, if
+care is not taken when broadcasting packets. Router must not send
+the broadcast packet to any other route except to its primary route.
+
+If the primary route of the router is the original sender of the packet
+the packet must not be sent to the primary route. This may happen
+if router has several router connections and some other router uses
+the router as its primary route.
+
+Routers use broadcast packets to broadcast for example information
+about newly registered clients, servers, channels etc. so that all the
+routers may keep these informations up to date.
+
+
+.ti 0
+2.14 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
Finland
EMail: priikone@poseidon.pspt.fi
+
+This Internet-Draft expires 13 May 2001
projects / runtime.git / blobdiff