From 77599da05bae9b355f600d63f9be8c285ff0ea4d Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Fri, 22 Mar 2002 16:16:08 +0000 Subject: [PATCH] updates. --- doc/draft-riikonen-silc-commands-03.nroff | 2 +- ...raft-riikonen-silc-flags-payloads-00.nroff | 303 ++++++++++++++++++ doc/draft-riikonen-silc-ke-auth-05.nroff | 2 +- doc/draft-riikonen-silc-pp-05.nroff | 24 +- doc/draft-riikonen-silc-spec-05.nroff | 2 +- 5 files changed, 318 insertions(+), 15 deletions(-) create mode 100644 doc/draft-riikonen-silc-flags-payloads-00.nroff diff --git a/doc/draft-riikonen-silc-commands-03.nroff b/doc/draft-riikonen-silc-commands-03.nroff index 64e3d44f..20c7d47f 100644 --- a/doc/draft-riikonen-silc-commands-03.nroff +++ b/doc/draft-riikonen-silc-commands-03.nroff @@ -1959,7 +1959,7 @@ Snellmanninkatu 34 A 15 70100 Kuopio Finland -EMail: priikone@silcnet.org +EMail: priikone@iki.fi This Internet-Draft expires XXX diff --git a/doc/draft-riikonen-silc-flags-payloads-00.nroff b/doc/draft-riikonen-silc-flags-payloads-00.nroff new file mode 100644 index 00000000..00c7902f --- /dev/null +++ b/doc/draft-riikonen-silc-flags-payloads-00.nroff @@ -0,0 +1,303 @@ +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Riikonen +.ds RF FORMFEED[Page %] +.ds CF +.ds LH Internet Draft +.ds RH XXX +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-flags-payloads-00.txt XXX +Expires: XXX + +.in 3 + +.ce 3 +SILC Message Flag Payloads + + +.ti 0 +Status of this Memo + +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." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. + + +.ti 0 +Abstract + +This memo describes the data payloads associated with the SILC Message +Flags, as defined in the SILC Packet Protocol Internet Draft [SILC2]. The +purpose of the Message Flags is to augment the function of the Private +Message Payload and Channel Message Payload by allowing the sender to +tell the receiver what type of data the payload includes, and how the +data should be processed. Some of the Message Flags may define additional +payloads to be associated with the flag, and this memo describes these +payloads. + + + + + + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. x + 1.1 Requirements Terminology .................................. x +2 SILC Message Flags ............................................ x +3 SILC Message Flag Payloads .................................... x + 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. x + 3.2 SILC_MESSAGE_FLAG_REPLY ................................... x + 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. x + 3.4 SILC_MESSAGE_FLAG_DATA .................................... x +4 Security Considerations ....................................... x +5 References .................................................... x +6 Author's Address .............................................. x + + +.ti 0 +1. Introduction + +The Secure Internet Live Conferencing [SILC1] supports sending binary +messages between users in the network. To make the data sending, and +processing at the receiver's end as simple as possible the SILC defines +Message Flags to the Private Message Payload and Channel Message Payload +[SILC2], which can help the receiver to decide how the data is encoded, +and how it should be interpreted. Some of the Message Flags may define +additional payloads to be associated with the flag, but the [SILC2] does +not define them. This memo defines the payloads for those Message Flags +that was marked to include additional payloads in [SILC1]. + +By defining the payloads for the Message Flags the SILC message payloads +can be augmented to support any kind of data, which can be easily +interpreted at the receiver end. For example, it would be possible to +send audio stream, video stream, image files and HTML pages as messages, +and the receiver can either choose to ignore the message or to process +it, or to perhaps pass the message to some application for processing. +Without specific payloads for Message Flags it is almost impossible for +the receiver to interpret binary data from the payload. + + +.ti 0 +1.1 Requirements Terminology + +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +MAY, and OPTIONAL, when they appear in this document, are to be +interpreted as described in [RFC2119]. + + +.ti 0 +2 SILC Message Flags + +The Message Flags was added to the SILC protocol for the reason that SILC +provides sending binary data as messages between users, and entities in +the network, and interpreting pure binary data is almost impossible. +With the flags the purpose, the reason, and the way the message is +supposed to be interpreted can be told to the recipient. Other +conferencing protocols which are usually ASCII based protocols do not have +such problems since they do not generally support sending of binary data +at all, or require encoding of the data before it can be sent over the +network. + +SILC Private Message Payload and Channel Message Payload can have flags +that can augment the function of the payload. The flags can tell for +example that the message is a request, or a reply to an earlier received +request. They can tell that the message is some action that the sender +is performing, or they can tell that the message is an auto reply, or +that it is explicitly digitally signed by the sender. + +The problem of Message Flags is that the space for flags mask is only 16 +bits, so there is a limited number of flags available. For this reason a +flag that defines some generic way of sending any kind of data as a +message, and that it can be easily interpreted at the receiver's end is +important. For this reason the flag SILC_MESSAGE_FLAG_DATA was added to +the protocol which can represent any data. This memo desribes how this +flag is used and how the associated payload is constructed and processed. +This memo also describes payloads for all the other flags that can have +associated payloads. + + +.ti 0 +3 SILC Message Flag Payloads + +The [SILC2] defines the flags which may have associated payloads. This +section will list these flags and define the payloads. + + +.ti 0 +3.1 SILC_MESSAGE_FLAG_REQUEST + +Currently this flag can be used in the context of application specific, +service specific or vendor specific requests, and the data payload type is +dependent of this context. Therefore, payload is not defined for this +flag in this memo. This flag may also be masked with some other flag in +the message payload, including with some other flag that defines +additional payload. + + +.ti 0 +3.2 SILC_MESSAGE_FLAG_REPLY + +Currently this flag can be used in the context of application specific, +service specific or vendor specific replies, and the data payload type is +dependent of this context. Therefore, payload is not defined for this +flag in this memo. This flag may also be masked with some other flag in +the message payload, including with some other flag that defines +additional payload. + + +.ti 0 +3.3 SILC_MESSAGE_FLAG_SIGNED + +Not defined yet. + + +.ti 0 +3.4 SILC_MESSAGE_FLAG_DATA + +This flag is used to represent any data as a message in the way that it +can be easily interpreted by the recipient. This flag is used to send +MIME objects as messages from the sender to the receiver. The MIME as +defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is +well established protocol for sending different kind of data with many +applications and protocols. It support dozens of different media types +and encodings, and for this reason is ideal for sending data in SILC +message payloads as well. + +When the receiver has checked that the message payload includes the +SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header. +It would also be possible to pass the message to some application which +can already interpret MIME objects. If the receiver does not support the +media type received in the MIME header, it SHOULD be treated as +"application/octet-stream". The receiver MAY also ignore and discard +messages that it does not support. + +The MIME header MUST be at the start of the data area of the Private +Message Payload or Channel Message Payload. The MIME header received in +the data area of the payload SHOULD have the MIME-Version field at first +and then Content-Type field. The MIME-Version field is not required to be +present in each body part of multipart entity. Additionally the header +MAY also include any other MIME compliant headers. The character encoding +for the MIME Header strings inside the message payload is US-ASCII, as +defined in [RFC2045]. The actual MIME object may define additional +character sets or encodings for the data it delivers. + +Hence, the MIME Header in the message payload may be as follows: + +.in 8 +.nf +MIME-Version: 1.0 +Content-Type: discrete/composite +Content-Transfer-Encoding: binary +.in 3 + +The Content-Transfer-Encoding field behaves as defined in [RFC2045] and +defines the encoding of the data in the MIME object. The preferred data +encoding with SILC is "binary". However, many MIME media types defines +their preferred encoding and they may be used if binary encoding is not +suitable. + +When sending large amounts of traffic or large files as MIME objects the +limits of the SILC Packet needs to be taken into consideration. The +maximum length of SILC Packet is 2^16 bytes, and larger messages would +need to be fragmented. MIME provides way of fragmenting and reassembling +messages, and it is to be done with SILC as defined in [RFC2046]. The +MIME fragmentation is defined for gateway usage, but in case of SILC the +sender may also start sending fragmented MIME objects. + +This flag SHOULD NOT be masked with some other Message Flag that defines +payloads. Generally this sort of setting would be impossible for the +receiver to interpret. However, flags that does not define any specific +payloads MAY be masked with this flag as well. For example, this flag +could be masked also with SILC_MESSAGE_FLAG_REQUEST flag. + + +.ti 0 +4 Security Considerations + +In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special +attention to the security implications of any media type that can cause +the remote execution of any actions in the receiver's environment. The +[RFC2046] and [RFC2048] discusses more MIME specific security +considerations. Even though SILC provides secured messages, in case of +MIME which can be used to transfer files and documents which are stored in +the receiver's local environment, securing separately the MIME object may +be desired. For example, augmenting the MIME support in SILC messages to +support S/MIME may be desired in some implementations. + + + +.ti 0 +5 References + +[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, April 2001. + +[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + April 2001. + +[RFC2045] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part One: Format of Internet Message Bodies", + Standards Track, RFC 2045, November 1996. + +[RFC2046] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part Two: Media Types", Standards Track, RFC 2045, + November 1996. + +[RFC2047] Moore K., "MIME (Multipurpose Internet Mail Extensions) + Part Three: Message Header Extensions for Non-ASCII Text" + Standards Track, RFC 2047, November 1996. + +[RFC2048] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part Four: Registration Procedures", Standards + Track, RFC 2048, November 1996. + +[RFC2049] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part Five: Conformance Criteria and Examples", + Standards Track, RFC 2049, November 1996. + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +.ti 0 +6 Author's Address + +Pekka Riikonen +Snellmanninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@iki.fi + +This Internet-Draft expires XXX diff --git a/doc/draft-riikonen-silc-ke-auth-05.nroff b/doc/draft-riikonen-silc-ke-auth-05.nroff index 846d7689..4e207e4f 100644 --- a/doc/draft-riikonen-silc-ke-auth-05.nroff +++ b/doc/draft-riikonen-silc-ke-auth-05.nroff @@ -1111,6 +1111,6 @@ Snellmanninkatu 34 A 15 70100 Kuopio Finland -EMail: priikone@silcnet.org +EMail: priikone@iki.fi This Internet-Draft expires XXX diff --git a/doc/draft-riikonen-silc-pp-05.nroff b/doc/draft-riikonen-silc-pp-05.nroff index c8a5a908..d31a2e2f 100644 --- a/doc/draft-riikonen-silc-pp-05.nroff +++ b/doc/draft-riikonen-silc-pp-05.nroff @@ -1532,7 +1532,7 @@ represents the Channel Message Payload. 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 ~ @@ -1559,11 +1559,11 @@ Figure 13: Channel Message Payload .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 @@ -1777,7 +1777,7 @@ diagram represents the Private Message Payload. 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 ~ @@ -1794,10 +1794,10 @@ Figure 15: Private Message Payload .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. @@ -2814,6 +2814,6 @@ Snellmanninkatu 34 A 15 70100 Kuopio Finland -EMail: priikone@silcnet.org +EMail: priikone@iki.fi This Internet-Draft expires XXX diff --git a/doc/draft-riikonen-silc-spec-05.nroff b/doc/draft-riikonen-silc-spec-05.nroff index 71f67d6f..e5181fdd 100644 --- a/doc/draft-riikonen-silc-spec-05.nroff +++ b/doc/draft-riikonen-silc-spec-05.nroff @@ -2234,6 +2234,6 @@ Snellmanninkatu 34 A 15 70100 Kuopio Finland -EMail: priikone@silcnet.org +EMail: priikone@iki.fi This Internet-Draft expires XXX -- 2.24.0