.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 15 January 2007
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-pp-08.txt XXX
-Expires: XXX
+draft-riikonen-silc-pp-09.txt 15 January 2007
+Expires: 15 July 2007
.in 3
<draft-riikonen-silc-pp-09.txt>
.ti 0
-Status of this Memo
+Status of this Draft
-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.
+By submitting this Internet-Draft, each author represents that any
+applicable patent or other IPR claims of which he or she is aware
+have been or will be disclosed, and any of which he or she becomes
+aware will be disclosed, in accordance with Section 6 of BCP 79.
-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 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".
The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
+http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
+http://www.ietf.org/shadow.html.
-The distribution of this memo is unlimited.
.ti 0
2 SILC Packet Protocol .......................................... 4
2.1 SILC Packet ............................................... 4
2.2 SILC Packet Header ........................................ 5
- 2.3 SILC Packet Types ......................................... 7
+ 2.3 SILC Packet Types ......................................... 8
2.3.1 SILC Packet Payloads ................................ 15
- 2.3.2 Generic payloads .................................... 15
- 2.3.2.1 ID Payload .................................. 15
- 2.3.2.2 Argument Payload ............................ 16
+ 2.3.2 Generic payloads .................................... 16
+ 2.3.2.1 ID Payload .................................. 16
+ 2.3.2.2 Argument Payload ............................ 17
2.3.2.3 Argument List Payload ....................... 17
2.3.2.4 Channel Payload ............................. 18
2.3.2.5 Public Key Payload .......................... 19
- 2.3.2.6 Message Payload ............................. 19
+ 2.3.2.6 Message Payload ............................. 20
2.3.3 Disconnect Payload .................................. 23
- 2.3.4 Success Payload ..................................... 23
- 2.3.5 Failure Payload ..................................... 24
+ 2.3.4 Success Payload ..................................... 24
+ 2.3.5 Failure Payload ..................................... 25
2.3.6 Reject Payload ...................................... 25
- 2.3.7 Notify Payload ...................................... 25
- 2.3.8 Error Payload ....................................... 34
+ 2.3.7 Notify Payload ...................................... 26
+ 2.3.8 Error Payload ....................................... 35
2.3.9 Channel Message Payload ............................. 35
- 2.3.10 Channel Key Payload ................................ 35
- 2.3.11 Private Message Payload ............................ 37
- 2.3.12 Private Message Key Payload ........................ 37
- 2.3.13 Command Payload .................................... 39
- 2.3.14 Command Reply Payload .............................. 40
- 2.3.15 Connection Auth Request Payload .................... 40
+ 2.3.10 Channel Key Payload ................................ 36
+ 2.3.11 Private Message Payload ............................ 38
+ 2.3.12 Private Message Key Payload ........................ 38
+ 2.3.13 Command Payload .................................... 40
+ 2.3.14 Command Reply Payload .............................. 41
+ 2.3.15 Connection Auth Request Payload .................... 41
2.3.16 New ID Payload ..................................... 42
- 2.3.17 New Client Payload ................................. 42
- 2.3.18 New Server Payload ................................. 43
- 2.3.19 New Channel Payload ................................ 44
+ 2.3.17 New Client Payload ................................. 43
+ 2.3.18 New Server Payload ................................. 44
+ 2.3.19 New Channel Payload ................................ 45
2.3.20 Key Agreement Payload .............................. 45
- 2.3.21 Resume Router Payload .............................. 46
+ 2.3.21 Resume Router Payload .............................. 47
2.3.22 File Transfer Payload .............................. 47
2.3.23 Resume Client Payload .............................. 48
- 2.4 SILC ID Types ............................................. 49
- 2.5 Packet Encryption And Decryption .......................... 49
- 2.5.1 Normal Packet Encryption And Decryption ............. 50
- 2.5.2 Channel Message Encryption And Decryption ........... 50
- 2.5.3 Private Message Encryption And Decryption ........... 51
- 2.6 Packet MAC Generation ..................................... 52
- 2.7 Packet Padding Generation ................................. 53
- 2.8 Packet Compression ........................................ 53
- 2.9 Packet Sending ............................................ 54
- 2.10 Packet Reception ......................................... 54
- 2.11 Packet Routing ........................................... 54
- 2.12 Packet Broadcasting ...................................... 56
-3 Security Considerations ....................................... 56
-4 References .................................................... 56
-5 Author's Address .............................................. 58
-6 Full Copyright Statement ...................................... 58
+ 2.3.24 Acknowledgement Payload ............................ 50
+ 2.4 SILC ID Types ............................................. 50
+ 2.5 Packet Encryption And Decryption .......................... 51
+ 2.5.1 Normal Packet Encryption And Decryption ............. 51
+ 2.5.2 Channel Message Encryption And Decryption ........... 52
+ 2.5.3 Private Message Encryption And Decryption ........... 53
+ 2.6 Packet MAC Generation ..................................... 53
+ 2.7 Packet Padding Generation ................................. 54
+ 2.8 Packet Compression ........................................ 54
+ 2.9 Packet Sending ............................................ 55
+ 2.10 Packet Reception ......................................... 55
+ 2.11 Packet Routing ........................................... 55
+ 2.12 Packet Broadcasting ...................................... 57
+3 Security Considerations ....................................... 57
+4 References .................................................... 57
+5 Author's Address .............................................. 59
+6 Full Copyright Statement ...................................... 59
.ti 0
List of Figures
Indicates that the packet data MUST include private
message that is encrypted using private key set by
client. Servers does not know this key and cannot
- handle the packet, but passes it along. See section
- 2.5.3 Private Message Encryption And Decryption for
- more information.
+ decrypt the payload, but simply passes it along. See
+ section 2.5.3 Private Message Encryption And Decryption
+ for more information.
List 0x02
See section 2.8 Packet Compression for description of
packet compressing.
+
+ Acknowledgement 0x10
+
+ Marks that the packet needs to be acknowledged by the
+ recipient. The ACK packet MUST NOT have this flag set.
+ The acknowledgement packet is SILC_PACKET_ACK packet.
+ If the packet is not acknowledged the packet may be
+ retransmitted. This flag is especially useful when
+ using UDP/IP and SHOULD NOT be used with TCP/IP. The
+ flag MUST NOT be used with message packets. The
+ SILC_MESSAGE_FLAG_ACK can be used instead. Broadcast
+ packets MUST NOT set this flag. Retransmission
+ may use for example exponential backoff algorithm.
+
.in 3
o Packet Type (1 byte) - Indicates the type of the packet.
Payload of the packet: See section 2.3.23 Resume Client Payload
- 29 - 199
+ 29 SILC_PACKET_ACK
+
+ This packet is used to acknowledge a packet that had the
+ Acknowledgement packet flag set.
+
+ Payload of the packet: See section 2.3.24 Acknowledgement
+ Payload
+
+
+ 30 - 199
Currently undefined commands.
The IV SHOULD be random data for each channel message.
When encrypting private messages with session keys this
- field MUST NOT be present. For private messages this
- field is present only when encrypting with a static
- private message key (pre-shared key). If randomly
- generated key material is used this field MUST NOT be
- present. Also, If Key Agreement (SKE) was used to
- negotiate fresh key material for private message key
- this field MUST NOT be present. See the section 4.6
- in [SILC1] for more information about IVs when
- encrypting private messages.
+ field MUST NOT be present. For private messages this field
+ is present only when encrypting with a static private
+ message key (pre-shared key). If randomly generated key
+ material is used this field MUST NOT be present. Also,
+ If Key Agreement (SKE) was used to negotiate fresh key
+ material for private message key this field MUST NOT be
+ present. See the section 4.6 in [SILC1] for more
+ information about IVs when encrypting private messages.
This field includes the initialization vector used in message
encryption. It need to be used in the packet decryption
and receiver can use the MAC to verify which of the keys
must be used in decryption. This field is not present
when encrypting private messages with session key. This
- field is not encrypted. This field is authenticated by
+ field is not encrypted. This field is authenticated by
the SILC packet MAC.
.in 3
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. This notify
- MUST NOT be sent to the quitting client.
+ MUST NOT be sent to the quitting client. The Destination ID
+ in the packet may be any ID depending to who it is destined.
Max Arguments: 2
Arguments: (1) <Client ID> (2) <message>
field.
o Channel Key (variable length) - The actual channel key
- material.
+ material. See [SILC1] on how to start using the key.
.in 3
The message can be protected by the session key established by the
SILC Key Exchange Protocol. However, it is also possible to agree
-to use a private key to protect just the private messages. It is
-for example possible to perform Key Agreement between two clients.
-See section 2.3.20 Key Agreement Payload how to perform key
-agreement. It is also possible to use static or pre-shared keys
+to use a private message key to protect just the private messages.
+It is for example possible to perform Key Agreement between two
+clients. See section 2.3.20 Key Agreement Payload how to perform
+key agreement. It is also possible to use static or pre-shared keys
to protect private messages. See the 2.3.12 Private Message Key
Payload and [SILC1] section 4.6 for detailed description for private
message key generation.
detailed description how the detaching and resuming procedure is
performed.
-The payload may only be sent with SILC_PACKET_RESUME CLIENT packet. It
+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 3
+.ti 0
+2.3.24 Acknowledgement Payload
+
+This payload is used to acknowledge a packet that had the Acknowledgement
+packet flag set. The payload includes the sequence number of the packet
+that had the flag set, which the recipient can use to identify that the
+packet was acknowledged.
+
+The payload may only be sent with SILC_PACKET_ACK packet. It
+MUST NOT be sent in any other packet type. The following diagram
+represents the Acknowledgement 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Packet Sequence Number |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 24: Resume Client Payload
+
+
+.in 6
+o Packet Sequence Number (4 bytes) - The packet sequence number
+ of the packet that had the Acknowledgement flag set.
+.in 3
+
.ti 0
2.4 SILC ID Types
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
-example, when they are routing channel message to the local clients.
+of packet routing. Normal servers performs packet forwarding, for
+example, when they are forwarding channel message to the local clients.
Routing is quite simple as every packet tells the true origin and the
true destination of the packet.
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 an entity that is
+For server which receives a packet to be forwarded to an entity that is
indirectly connected to the sender, the server MUST check whether that
-particular packet type is allowed to be routed to that destination. Not
+particular packet type is allowed to be sent to that destination. Not
all packets may be sent by some odd entity to for example a local client,
or to some remote server or router, that is indirectly connected to the
sender. See section 2.3 SILC Packet Types and paragraph about indirectly
4 References
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
- Protocol Specification", Internet Draft, May 2002.
+ Protocol Specification", Internet Draft, January 2007.
[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
- Protocols", Internet Draft, May 2002.
+ Protocols", Internet Draft, January 2007.
-[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
.nf
Pekka Riikonen
-Snellmaninkatu 34 A 15
-70100 Kuopio
+Helsinki
Finland
EMail: priikone@iki.fi
.ti 0
6 Full Copyright Statement
-Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implementation may be prepared, copied, published
-and distributed, in whole or in part, without restriction of any
-kind, provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of
-developing Internet standards in which case the procedures for
-copyrights defined in the Internet Standards process must be
-followed, or as required to translate it into languages other than
-English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Copyright (C) The Internet Society (2007).
+
+This document is subject to the rights, licenses and restrictions
+contained in BCP 78, and except as set forth therein, the authors
+retain all their rights.
+
+This document and the information contained herein are provided on an
+"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
projects / silc.git / blobdiff