Open Pluggable Edge Services (OPES) SMTP Use Cases
draft-ietf-opes-smtp-use-cases-06

Open Pluggable Edge Services                                  M. Stecher
Internet-Draft                                                CyberGuard
Expires: July 14, 2006                                         A. Barbir
                                                         Nortel Networks
                                                        January 10, 2006

                          OPES SMTP Use Cases
                   draft-ietf-opes-smtp-use-cases-06

Status of this Memo

   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 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.

   This Internet-Draft will expire on July 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Open Pluggable Edge Services (OPES) framework is application
   agnostic.  Application specific adaptations extend that framework.
   This document describes OPES SMTP use cases and deployment scenarios
   in preparation for SMTP adaptation with OPES.

Stecher & Barbir          Expires July 14, 2006                 [Page 1]
Internet-Draft             OPES SMTP Use Cases              January 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Brief overview of SMTP Architecture  . . . . . . . . . . . . .  5
     3.1   Operation Flow of an OPES SMTP System  . . . . . . . . . .  6
       3.1.1   OPES SMTP Example  . . . . . . . . . . . . . . . . . .  7
   4.  OPES/SMTP Use Cases  . . . . . . . . . . . . . . . . . . . . .  9
     4.1   Security filters applied to email messages . . . . . . . .  9
     4.2   Spam Filter  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   Logging and reporting filters  . . . . . . . . . . . . . . 10
     4.4   Access control filters . . . . . . . . . . . . . . . . . . 10
     4.5   Secure Email handling  . . . . . . . . . . . . . . . . . . 10
     4.6   Email format normalization . . . . . . . . . . . . . . . . 11
     4.7   Mail rerouting and address rewriting . . . . . . . . . . . 11
     4.8   Block email during SMTP dialog . . . . . . . . . . . . . . 11
     4.9   Convert attachments to HTTP links  . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1   Normative References . . . . . . . . . . . . . . . . . . . 14
     6.2   Informative References . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 17

Stecher & Barbir          Expires July 14, 2006                 [Page 2]
Internet-Draft             OPES SMTP Use Cases              January 2006

1.  Introduction

   The Open Pluggable Edge Services (OPES) architecture [1] enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.  The OPES processor can distribute
   the responsibility of service execution by communicating and
   collaborating with one or more remote callout servers.

   The execution of such services is governed by a set of rules
   installed on the OPES processor.  The rule evaluation can trigger the
   execution of service applications local to the OPES processor or on a
   remote callout server.

   HTTP [8] based use cases for Open Pluggable Edge Services (OPES) are
   described in [2].  This work focuses on OPES for SMTP [7] use cases,
   whereby, additional use cases and enhancements to the types of OPES
   services defined in [2] are provided.

   In SMTP the OPES processor may be any agent participating in SMTP
   exchanges, including a Mail Submission Agent (MSA), a Mail Transfer
   Agent (MTA), a Mail Delivery Agent (MDA), and a Mail User Agent
   (MUA).  This document focuses on use cases in which the OPES
   processor is a mail transfer agent (MTA).

   SMTP is a store and forward protocol.  Current email filtering
   systems either operate during the SMTP exchange or on messages that
   have already been received, after the SMTP connection has been closed
   (for example, in an MTA's message queue).

   This work focuses on SMTP based services that want to modify command
   values or want to block SMTP commands.  In order to block a command
   the service will provide an error message that the MTA should use in
   response to the command it received.  An OPES MTA will be involved in
   SMTP command modification and command satisfaction, analogous to
   request modification and request satisfaction from HTTP [8].

Stecher & Barbir          Expires July 14, 2006                 [Page 3]
Internet-Draft             OPES SMTP Use Cases              January 2006

2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [6].  When used with
   the normative meanings, these keywords will be all uppercase.
   Occurrences of these words in lowercase comprise normal prose usage,
   with no normative implications.

Stecher & Barbir          Expires July 14, 2006                 [Page 4]
Internet-Draft             OPES SMTP Use Cases              January 2006

3.  Brief overview of SMTP Architecture

   The SMTP design, taken from RFC 2821 [7] is shown in Figure 1.  When
   an SMTP client has a message to transmit, it establishes a two-way
   transmission channel to an SMTP server.  The responsibility of an
   SMTP client is to transfer mail messages to one or more SMTP servers,
   or report its failure to do so.

                  +----------+                +----------+
      +------+    |          |                |          |
      | User |<-->|          |      SMTP      |          |
      +------+    |  Client  |Commands/Replies| Server   |
      +------+    |   SMTP   |<-------------->|  SMTP    |    +------+
      | File |<-->|          |    and Mail    |          |<-->| File |
      |System|    |          |                |          |    |System|
      +------+    +----------+                +----------+    +------+
                   SMTP client                SMTP server

                           Figure 1: SMTP Design

   In some cases, the domain name(s) transferred to, or determined by,
   an SMTP client will identify the final destination(s) of the mail
   message.  In other cases, the domain name determined will identify an
   intermediate destination through which those mail messages are to be
   relayed.

   An SMTP server may be either the ultimate destination or an
   intermediate "relay" or "gateway" (that is, it may transport the
   message further using some protocol other than SMTP or using again
   SMTP and then acting as an SMTP client).

   SMTP commands are generated by the SMTP client and sent to the SMTP
   server.  SMTP responses are sent from the SMTP server to the SMTP
   client in response to the commands.  SMTP message transfer can occur
   in a single connection between the original SMTP-sender and the final
   SMTP-recipient, or can occur in a series of hops through intermediary
   systems.  SMTP clients and servers exchange commands and responses
   and eventually the mail message body.

   Figure 2 expands on the mail flow in an SMTP system.  Further
   information about the architecture of email in the Internet may be
   found in [9].

Stecher & Barbir          Expires July 14, 2006                 [Page 5]
Internet-Draft             OPES SMTP Use Cases              January 2006

   +-------+  +---------+      +---------+      +--------+  +-------+
   |mail  M|  |M mail  M| SMTP |M mail  M| SMTP |M mail M|  |M mail |
   |clnt  U|--|S srvr  T|------|T gway  T|------|T srvr D|--|U clnt |
   |      A|  |A       A|      |A       A|      |A      A|  |A      |
   +-------+  +---------+      +---------+      +--------+  +-------+

                       Figure 2: Expanded SMTP Flow

   In this work the OPES processor may be any agent that is
   participating in SMTP exchanges, including an MSA, MTA, MDA, and MUA.
   However, this document focuses on use cases in which the OPES
   processor uses the SMTP protocol or one of the protocols derived from
   SMTP (SUBMIT [10] and LMTP [11]).

3.1  Operation Flow of an OPES SMTP System

   In this work an MTA is the OPES processor device that sits in the
   data stream of the SMTP protocol.  The OPES processor gets enhanced
   by an OCP (OPES callout protocol) [3] client that allows it to vector
   out data to the callout server.  The filtering functionality is on
   the callout server.

   A client (a mail user) starts with an email client program (MUA).
   The user sends email to an outgoing email server.  In the email
   server there is an MSA (mail submission agent) that is waiting to
   receive email from the user.  The MSA uses an MTA (mail transfer
   agent) within the same server to forward the user email to other
   domains.  (Communication between the MUA and MSA may be via SMTP,
   SUBMIT [10], or something else such as MAPI).

   The MTA in the user email server may directly contact the email
   server of the recipient or may use other intermediate email gateways.
   The sending email server and all intermediate gateway MTAs usually
   communicate using SMTP.  Communication with the destination email
   server usually uses SMTP, or its derivative LMTP [11].

   In the destination email server a mail delivery agent (MDA) may
   deliver the email to the recipient's mailbox.  The email client
   program of the recipient might use a different protocol (such as POP3
   or IMAP) to access the mailbox and retrieve/read the messages.

Stecher & Barbir          Expires July 14, 2006                 [Page 6]
Internet-Draft             OPES SMTP Use Cases              January 2006

   +-------+  +---------+      +---------+      +--------+  +-------+
   |mail  M|  |M mail  M| SMTP |M mail  M| SMTP |M mail M|  |M mail |
   |clnt  U|--|S srvr  T|------|T gway  T|------|T srvr D|--|U clnt |
   |      A|  |A       A|      |A       A|      |A      A|  |A      |
   +-------+  +---------+      +---------+      +--------+  +-------+
                   |                |                |
                   | OCP            | OCP            | OCP
                   |                |                |
              +----------+     +----------+     +----------+
              |  callout |     |  callout |     |  callout |
              |  server  |     |  server  |     |  server  |
              +----------+     +----------+     +----------+

                         Figure 3: OPES SMTP Flow

   From Figure 3, the MTA (the OPES processor) is either receiving or
   sending an email (or both) within an email server/gateway.  An OPES
   processor might be the sender's SMTP server, the destination SMTP
   server or any intermediate SMTP gateway.  (Which building block
   belongs to which authoritative domain is an important question but
   different from deployment to deployment).  Note that this figure
   shows multiple different OPES deployment options in a typical chain
   of mail servers and gateways with different roles as MSA, MTA and
   MDA; the OPES standard case however will only have a single OPES
   processor and a single callout server in the message flow.

3.1.1  OPES SMTP Example

   A typical (minimum) SMTP dialog between two OPES SMTP processors
   (MTA) will consist of the following (C: means client, S: means
   server):

      S: 220 mail.example.com Sample ESMTP MAIL Service, Version: 1.2
      ready at Thu, 20 Jan 2005 11:24:40+0100
      C: HELO [192.0.2.138]
      S: 250 mail.example.com Hello [192.0.2.138]
      C: MAIL FROM:<steve@example.org>
      S: 250 2.1.0 steve@example.org....Sender OK
      C: RCPT TO:<paul@example.com>
      S: 250 2.1.5 paul@example.com
      C: DATA
      S: 354 Start mail input; end with "CRLF"."CRLF"
      C: From: steve@example.org
      C: To: sandra@example.com
      C: Subject: Test
      C:
      C: Hi, this is a test!
      C: .

Stecher & Barbir          Expires July 14, 2006                 [Page 7]
Internet-Draft             OPES SMTP Use Cases              January 2006

      S: 250 2.6.0 "MAIL0m4b1f@mail.example.com" Queued mail for
      delivery
      C: QUIT
      S: 221 2.0.0 mail.example.com Service closing transmission channel

   The client (C:) is issuing SMTP commands and the server (S:) is
   generating responses.  All responses start with a status code and
   then some text.  At minimum 4 commands are needed to send an email.
   All commands and responses to send a single email message together
   form "the dialog".  The mail message body is the data sent after the
   "DATA" command.  An OPES processor could see that as command
   modification.

   If a callout service wants to adapt the email message body, it is
   mainly interested in this part of the dialog:

      From: steve@example.org
      To: sandra@example.com
      Subject: Test

      Hi, this is a test!

   The callout service may need to examine values of previous commands
   of the same dialog.  For example, the callout service needs to
   examine the value of the RCPT command (it is "paul@example.com")
   which is different from the "sandra@example.com" that the email
   client displays in the visible "To" field.  That might be an
   important fact for some filters such as Spam Filters (Section 4.2).

Stecher & Barbir          Expires July 14, 2006                 [Page 8]
Internet-Draft             OPES SMTP Use Cases              January 2006

4.  OPES/SMTP Use Cases

   In principle, all filtering that is deployed at SMTP gateways today
   and tomorrow define use cases for OPES callout filtering.  An OCP/
   SMTP callout protocol will enable an SMTP gateway to vector out
   (parts of) an SMTP message or parts of the SMTP dialog to a callout
   server that is then performing actions on behalf of the gateway.
   (OCP/SMTP would be a profile defined for OCP analogous to the OCP/
   HTTP profile [4] that has been defined earlier.)

   Here is a collection of some typical use cases describing different
   filtering areas and different actions caused by those filters.

4.1  Security filters applied to email messages

   These filters concentrate on the email message body and usually
   filter the email sections one by one.  Email sections (attachments)
   that violate the security policy (because they for example contain a
   virus or contain an unwanted mime type) define an event that can
   cause a combination of different actions to be performed:

   o  The attachment is replaced by an error message

   o  The email is marked by inserting a warning into the subject or the
      email body

   o  An additional header is added for post-processing steps

   o  The email storage is advised to put the email into quarantine

   o  Notifications are sent to sender, recipients and/or administrators

   o  The incident is reported to other tools such as intrusion
      detection applications

   These kinds of filters usually do not require working with elements
   of the SMTP dialog other than the email message body.  An exception
   to this is the need to map email senders and recipients to different
   security sub policies that are used for a particular message.  A
   security filter may therefore require receiving the information of
   the RCPT TO and MAIL FROM commands as meta data with the email
   message body it examines.

4.2  Spam Filter

   Next to security filters, spam filters are probably the most wanted
   filtering application today.  Spam filters use several methods.  They
   concentrate most on the email message body (that also includes the

Stecher & Barbir          Expires July 14, 2006                 [Page 9]
Internet-Draft             OPES SMTP Use Cases              January 2006

   email headers) but many of these filters are also interested in the
   values of the other SMTP commands in order to compare the SMTP
   sender/recipients with the visible From/To fields.  They may even
   want to get the source IP of the connected SMTP client as meta
   information in order to verify this against lists of open relays,
   known spammers, etc.

   These are typical actions that could be performed when a message has
   been classified as spam:

   o  Add a mark to the subject of the email

   o  An additional header is added for post-processing steps

   o  The email storage is advised to put the email into a spam queue

   o  The email is rejected or returned to the sender

4.3  Logging and reporting filters

   The nature of this kind of filters is not to modify the email
   message.  Depending on what is being logged or reported on, the
   filter may need access to any part of the SMTP dialog.  Most wanted
   are the sender and recipient information.  Depending on the ability
   of the OPES processor to pre-calculate and transfer information about
   the message body, the callout filter may want to see the email
   message body itself or just that meta info; an example is the email
   size.  This information would be a typical logging and reporting
   information that is easy for the SMTP gateway to calculate although
   not a direct parameter of the SMTP dialog.  Transferring the complete
   email message body only because the callout server wants to calculate
   its size would be a waste of network resources.

4.4  Access control filters

   These filters operate on the values of the MAIL FROM and RCPT TO
   commands of the SMTP dialog.  They run an access control policy to
   determine whether a sender is currently allowed to send a message to
   the given recipients.  The values of HELO/EHLO, AUTH and STARTTLS
   commands may also be applied.  The result of this filter has a direct
   influence on the SMTP response that the OPES processor has to send to
   its peer for the filtered SMTP command.

4.5  Secure Email handling

   Filters of this kind can support an email gateway to centrally encode
   and decode email, and to set and to verify email signatures.  They

Stecher & Barbir          Expires July 14, 2006                [Page 10]
Internet-Draft             OPES SMTP Use Cases              January 2006

   will therefore modify the email message body to encrypt, decrypt,
   verify or sign the message, or use an action as specified in the
   "Security Filter" (Section 4.1) section if the decryption or
   signature verification fails.

   Sending the SMTP sender and recipient information as meta data to
   these filters is mission critical because these filters may not trust
   the information found in the header section of the email message
   body.

4.6  Email format normalization

   SMTP messages may be sent with illegal or uncommon format; this may
   have happened by a buggy SMTP application or on purpose in order to
   exploit vulnerabilities of other products.  A normalization filter
   can correct the email format.  The format correction can be done for
   the email body and for the value of other SMTP commands.  An example
   for the email body format correction would be a strange length of
   uuencoded lines or unusual names of MIME sections.  Command values
   may be analysed against buffer overflow exploits; a rewrite will not
   always be possible in this case (cannot simply rewrite an email
   address that is very long) but will require that the callout server
   tells the OPES processor to send an error response in reply to such a
   command.

4.7  Mail rerouting and address rewriting

   A corporation with multiple locations may want to deploy a central
   gateway that receives all email messages for all employees and then
   determines at which location the mail storage of the employee
   resides.  The callout server will then need the RCPT TO command value
   and looks up the location in the corporate directory service.  It
   then tells either the OPES processor where the next SMTP server is
   (i.e. the next SMTP server to connect to) or it rewrites the
   recipient address; in the first case the SMTP servers at the
   different locations accept emails of the same domain as the central
   gateway does; in the second case the other locations will probably
   use sub location of the original domain (joe@example.org ->
   joe@fr.example.org or joe@de.example.org)

4.8  Block email during SMTP dialog

   In a first step the callout server will check the sender and
   recipient information that was transmitted in the SMTP dialog; that
   information again maps to a policy that will either deny all messages
   from that sender or to that recipient.  Or it checks the body of the
   email and classifies it (maybe just by looking for some words in the
   subject or by doing in-depth content analysis), which can then also

Stecher & Barbir          Expires July 14, 2006                [Page 11]
Internet-Draft             OPES SMTP Use Cases              January 2006

   lead to the decision to deny the message.

   Unlike previous examples, this use case wants to deny the email while
   the SMTP dialog is still active, i.e. before the OPES processor
   finally accepted the message.  Depending on the exact policy the
   error response should then be sent in reply to the MAIL FROM, RCPT TO
   or DATA command.

4.9  Convert attachments to HTTP links

   This use case will only modify the email message body without any
   other influence on the SMTP dialogs, mail routing etc.  Larger
   sections (attachments) are removed from the email and the content is
   stored on a web server.  A link to that new URL is then added into
   the text of a first section that is likely to be displayed by an
   email client.  Storing the attachments onto the web server is not in
   the scope of the OPES/SMTP scenario and needs to be implemented by
   the callout server.

Stecher & Barbir          Expires July 14, 2006                [Page 12]
Internet-Draft             OPES SMTP Use Cases              January 2006

5.  Security Considerations

   Application-independent security considerations are documented in
   application-agnostic OPES specifications [5].  This document contains
   only use cases and defines no protocol operations.  Security
   considerations for protocols that appear in these use cases are
   documented in the corresponding protocol specifications.

   Use case "Secure Email handling" (Section 4.5) is special in this
   regard because it requires the extension of the end-to-end encryption
   model and a secure handling of private cryptographic keys when
   creating digital signatures or when decrypting messages.  Both are
   out of scope of OPES protocol specifications.  An implementation of
   such a service raises security issues (such as availability and
   storage of cryptographic keys) that must be addressed regardless of
   whether the implementation happens within an MTA or within an OPES
   callout server.

Stecher & Barbir          Expires July 14, 2006                [Page 13]
Internet-Draft             OPES SMTP Use Cases              January 2006

6.  References

6.1  Normative References

   [1]  Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
        Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
        August 2004.

   [2]  Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
        Penno, "Open Pluggable Edge Services (OPES) Use Cases and
        Deployment Scenarios", RFC 3752, April 2004.

   [3]  Rousskov, A., "Open Pluggable Edge Services (OPES) Callout
        Protocol (OCP) Core", RFC 4037, March 2005.

   [4]  Rousskov, A. and M. Stecher, "HTTP adaptation with OPES",
        draft-ietf-opes-http-03 (work in progress), April 2005.

   [5]  Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
        Orman, "Security Threats and Risks for Open Pluggable Edge
        Services (OPES)", RFC 3837, August 2004.

   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

6.2  Informative References

   [7]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [8]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [9]   Crocker, D., "Internet Mail Architecture",
         draft-crocker-email-arch-04 (work in progress), March 2005.

   [10]  Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
         December 1998.

   [11]  Myers, J., "Local Mail Transfer Protocol", RFC 2033,
         October 1996.

Stecher & Barbir          Expires July 14, 2006                [Page 14]
Internet-Draft             OPES SMTP Use Cases              January 2006

Authors' Addresses

   Martin Stecher
   CyberGuard Corporation
   Webwasher Division
   Vattmannstr. 3
   33100 Paderborn
   Germany

   Email: martin.stecher@webwasher.com
   URI:   http://www.cyberguard.com/

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario
   CA

   Phone: +1 613 763 5229
   Email: abbieb@nortelnetworks.com

Stecher & Barbir          Expires July 14, 2006                [Page 15]
Internet-Draft             OPES SMTP Use Cases              January 2006

Appendix A.  Acknowledgements

   Many thanks to everybody who provided input for the use case
   examples, namely jfc and Markus Hofmann.  Thanks also for the
   discussion and feedback given on the OPES mailing list.

Stecher & Barbir          Expires July 14, 2006                [Page 16]
Internet-Draft             OPES SMTP Use Cases              January 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Stecher & Barbir          Expires July 14, 2006                [Page 17]