SILC Header is always the first part of the packet and its purpose
is to provide information about the packet. It provides for example
the packet type, origin of the packet and the destination of the packet.
-The header is variable in length and first two (2) bytes of the
-header (thus first two bytes of the packet) are not encrypted. The
-first two (2) bytes are the length of the packet which is not encrypted.
-See the following section for description of SILC Packet header. Packets
-without SILC header or with malformed SILC header MUST be dropped.
+The header is variable in length. See the following section for
+description of SILC Packet header. Packets without SILC header or
+with malformed SILC header MUST be dropped.
Padding follows the packet header. The purpose of the padding is to
make the packet multiple by eight (8) or by the block size of the
cipher used in the encryption, which ever is larger. The maximum
-length of padding is currently 16 bytes. The padding is always
-encrypted.
+length of padding is currently 128 bytes. The padding is always
+encrypted. The padding is applied always, even if the packet is
+not encrypted. See the section 2.7 Padding Generation for more
+detailed information.
Data payload area follows padding and it is the actual data of the
packet. The packet data is the packet payloads defined in this
uses the packet header to parse the packet and gain other relevant
parameters of the packet.
-The following diagram represents the SILC packet header. (*) indicates
-that this field is never encrypted. Other fields are always encrypted.
+The following diagram represents the SILC packet header.
.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Payload Length * | Flags | Packet Type |
+| Payload Length | Flags | Packet Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Source ID Length | Destination ID Length |
+| Pad Length | RESERVED | Source ID Len | Dest ID Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src ID Type | |
+-+-+-+-+-+-+-+-+ +
.in 6
o Payload Length (2 bytes) - Is the length of the packet
- not including the padding of the packet. This field must
- not be encrypted but must always be authenticated.
+ not including the padding of the packet.
o Flags (1 byte) - Indicates flags to be used in packet
processing. Several flags may be set by ORing the flags
uses this field to parse the packet. See section 2.3
SILC Packets for list of defined packet types.
-o Source ID Length (2 bytes) - Indicates the length of the
+o Pad Length (1 byte) - Indicates the length of the padding
+ applied after the SILC Packet header. Maximum length for
+ padding is 128 bytes.
+
+o RESERVED (1 byte) - Reserved field and must include a
+ zero (0) value.
+
+o Source ID Length (1 byte) - Indicates the length of the
Source ID field in the header, not including this or any
other fields.
-o Destination ID Length (2 bytes) - Indicates the length of the
+o Destination ID Length (1 byte) - Indicates the length of the
Destination ID field in the header, not including this or
any other fields.
ID that indicates which is the end receiver of the packet.
+
.ti 0
2.3 SILC Packet Types
decryption is special. If the packet type is not among those special
packet types rest of the packet can be decrypted with the same key.
-Also, note that two bytes of the SILC Packet header are not encrypted
-thus it must be noticed in the decryption process by starting the
-decryption from the second byte of the header. This sets some rules
-to padding generation as well, see the section 2.7 Packet Padding
-Generation.
-
With out a doubt, this sort of decryption processing causes some
overhead to packet decryption, but never the less, is required.
The MAC key is negotiated during the SKE protocol. The sequence number
is a 32 bit MSB first value starting from zero for first packet and
increasing for subsequent packets, finally wrapping after 2^32 packets.
-The value is never reset, not even after rekey has been performed.
+The value is never reset, not even after rekey has been performed. Note
+that the sequence number is incremented only when MAC is computed for a
+packet. If packet is not encrypted and MAC is not computed then the
+sequence number is not incremented. Hence, the sequence number is zero
+for first encrypted packet.
See [SILC1] for defined and allowed MAC algorithms.
For normal packets the padding is added after the SILC Packet Header
and between the Data Payload area. The padding for normal packets
-are calculated as follows:
+may be calculated as follows:
.in 6
-padding length = 16 - ((packet length - 2) mod 16)
+padding length = 16 - (packet_length mod block_size)
.in 3
-The 16 is the maximum padding allowed in SILC packet. Two (2) is
-subtracted from the true length of the packet because two (2) bytes
-is not encrypted in SILC Packet Header, see section 2.2 SILC Packet
-Header. Those two bytes that are not encrypted MUST NOT be calculated
-to the padding length.
+The `block_size' is the block size of the cipher. The maximum padding
+length is 128 bytes, and minimum is 1 byte. The above algorithm calculates
+the padding to the next block size, and always returns the padding
+length between 1 - 16 bytes. However, implementations may add padding
+up to 128 bytes. For example packets that include a passphrase or a
+password for authentication purposes SHOULD pad the packet up to the
+maximum padding length.
-For special packets the padding calculation MAY be different as special
+For special packets the padding calculation is different as special
packets may be encrypted differently. In these cases the encrypted
data area MUST already be multiple by the block size thus in this case
the padding is calculated only for SILC Packet Header, not for any
other area of the packet. The same algorithm works in this case as
well, except that the `packet length' is now the SILC Packet Header
-length. In this case, as well, two (2) is subtracted from the
-length.
+length.
The padding MUST be random data, preferably, generated by
cryptographically strong random number generator.
destination does not exist in router's route cache the packet MUST be
routed to the primary route (default route).
+However, there are some issues when routing channel messages to group
+of users. Routers are responsible of routing the channel message to
+other routers, local servers and local clients as well. Routers MUST
+send the channel message to only one router in the network, preferrably
+to the shortest route to reach the channel users. The message can be
+routed into either upstream or downstream. After the message is sent
+to a router in the network it MUST NOT be sent to any other router in
+either same route or other route. The message MUST NOT be routed to
+the router it came from.
+
+When routing for example private messages they should be routed to the
+shortest route always to reach the destination client as fast as possible.
+
For server which receives a packet to be routed to its locally connected
client the server MUST check whether the particular packet type is
allowed to be routed to the client. Not all packets may be sent by
server cannot send, for example, disconnect packet to client that is not
directly connected to the server.
+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.
+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.
+The SILC protocol should have a shortest path discovery protocol, and some
+existing routing protocol, that can handle a ring network with other
+direct routes inside the ring (so called hybrid ring-mesh topology),
+MAY be defined to be used with the SILC protocol. Additional
+specifications MAY be written on the subject to permeate this
+specification.
+
.ti 0
2.12 Packet Broadcasting
projects / silc.git / blobdiff