DTN Research Group                                          S. Symington
Internet-Draft                                                  R. Durst
Intended status: Experimental                                   K. Scott
Expires: May 4, 2009                               The MITRE Corporation
                                                        October 31, 2008


        Delay-Tolerant Networking Bundle-in-Bundle Encapsulation
                draft-irtf-dtnrg-bundle-encapsulation-04

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 May 4, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).













Symington, et al.          Expires May 4, 2009                  [Page 1]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


Abstract

   This document defines an extension block that may be used with the
   Bundle Protocol [2] within the context of a Delay-Tolerant Network
   architecture [6].  When included as part of a given bundle B, this
   extension block, called a Bundle-in-Bundle Encapsulation Block,
   indicates that one or more other bundles have been placed inside of
   the payload field of B's Bundle Payload Block according to the format
   defined in this document.  Hence, the Bundle-in-Bundle Encapsulation
   Block provides a mechanism for bundle-in-bundle encapsulation by
   indicating that one or more bundles are being transmitted as the
   payload of a bundle.  This extension block is expected to be of
   general utility in DTN.  It may be used, for example, to encapsulate
   a multicast bundle inside of a unicast bundle, or to encapsulate a
   bundle with one type of security protection inside of a bundle with a
   different type of security protection.  This document defines the
   format and processing of this new Bundle-in-Bundle Encapsulation
   Block and the contents of the Bundle Payload Block accompanying it.

































Symington, et al.          Expires May 4, 2009                  [Page 2]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Bundle-in-Bundle Encapsulation Block Format  . . . . . . . . .  5
   3.  Bundle-in-Bundle Encapsulation Block Processing  . . . . . . .  7
     3.1.  Generation and Transmission of an Encapsulating Bundle . .  7
     3.2.  Receipt and Processing of an Encapsulating Bundle  . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16





































Symington, et al.          Expires May 4, 2009                  [Page 3]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   The DTN bundle protocol [2] defines the bundle as its protocol data
   unit.  A bundle consists of a primary bundle block followed by at
   least one other type of bundle block.  The Bundle Protocol currently
   defines a single other type of bundle block, called a Bundle Payload
   block.  This document defines an additional, optional, bundle block
   called a Bundle-in-Bundle Encapsulation Block.  The presence of this
   Bundle-in-Bundle Encapsulation Block in a bundle B indicates that one
   or more other bundles have been placed inside of the payload field of
   B's Bundle Payload Block according to the format defined in this
   document.  Hence, the Bundle-in-Bundle Encapsulation Block provides a
   mechanism for bundle-in-bundle encapsulation by indicating that one
   or more bundles are being transmitted as the payload of a bundle.
   This extension block is expected to be of general utility in DTN.  It
   may be used, for example, to encapsulate a multicast bundle inside of
   a unicast bundle, or to encapsulate a bundle with one type of
   security protection inside of a bundle with a different type of
   security protection.  This document defines the format and processing
   of this new Bundle-in-Bundle Encapsulation Block and the contents of
   the Bundle Payload Block accompanying it.

   The capabilities described in this document are OPTIONAL for
   deployment with the Bundle Protocol.  Bundle Protocol implementations
   claiming to support bundle-in-bundle encapsulation MUST be capable of
   both:

      -generating and transmitting bundles containing Bundle-in-Bundle
      Encapsulation Blocks, and

      -receiving and processing bundles containing Bundle-in-Bundle
      Encapsulation Blocks

   as defined in this document.













Symington, et al.          Expires May 4, 2009                  [Page 4]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


2.  Bundle-in-Bundle Encapsulation Block Format

   The Bundle-in-Bundle Encapsulation Block uses the Canonical Bundle
   Block Format as defined in the bundle protocol [2].  That is, it is
   comprised of the following elements:

      -Block-type code (1 byte) - defined as in all bundle protocol
      blocks except the primary bundle block (as described in the Bundle
      Protocol).  The block type code for the Bundle-in-Bundle
      Encapsulation Block is 0x10.

      -Block processing control flags (SDNV) - defined as in all bundle
      protocol blocks except the primary bundle block.  SDNV encoding is
      described in the Bundle Protocol.  Constraints on the values of
      the Block Processing Control Flags are as follows:

         -The "Delete bundle if block can't be processed" flag MUST NOT
         be set.

         -The "Discard block if it can't be processed" flag MUST NOT be
         set.

         -The "Block contains and EID-reference field" flag MUST NOT be
         set.

      -EID references (optional) - This composite field defined in the
      bundle protocol MUST NOT be present.

      -Block data length (SDNV) - defined as in all bundle protocol
      blocks except the primary bundle block.  SDNV encoding is
      described in the bundle protocol.  If the value of the SDNV in
      this field is 0, there are no remaining fields in the block, which
      indicates that exactly one bundle is present in the payload field
      of the bundle's Bundle Payload Block.

      -Block-type-specific data fields as follows:

         - Number of Encapsulated Bundles field (SDNV) (optional) -
         indicates the number N of bundles that are present in the
         payload field of the bundle's Bundle Payload Block, where N
         MUST be greater than 1.  (If only 1 bundle is present in the
         payload field of the Bundle Payload Block, the Number of
         Encapsulated Bundles field MUST NOT be present in the Bundle-
         in-Bundle Encapsulation block.)

         - Bundle Offsets List (optional) - contains the list of N-1
         offsets (each of which is an SDNV) of the beginning of each
         bundle that is located in payload field of the Bundle Payload



Symington, et al.          Expires May 4, 2009                  [Page 5]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


         Block after the first bundle in that field.  (The offset of the
         first bundle in the Bundle Payload Block is understood to be
         0.)  (If only 1 bundle is present in the payload field of the
         Bundle Payload Block, the Bundle Offsets List field MUST NOT be
         present in the Bundle-in-Bundle Encapsulation block.)

   The format of the bundle-in-bundle encapsulation block is as follows:

   Bundle-in-Bundle Encapsulation Block Format:
   +-----+------+------+------------------------+-----------------+
   |Type |Flags |Len   | Number of Encapsulated | Bundle Offsets  |
   |     |(SDNV)|(SDNV)|   Bundles(SDNV)(opt.)  |  List  (opt.)   |
   +-----+------+------+------------------------+-----------------+


                                 Figure 1



































Symington, et al.          Expires May 4, 2009                  [Page 6]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


3.  Bundle-in-Bundle Encapsulation Block Processing

   Instead of forwarding one or more bundles, a node MAY, according to
   local policy, encapsulate those bundle(s) by generating a new
   (encapsulating) bundle, placing the bundle(s) to be encapsulated into
   the payload field of the new bundle's Bundle Payload Block, creating
   a Bundle-in-Bundle Encapsulation block for the new bundle that
   includes the Number of Encapsulated Bundles (if greater than 1) and
   the offsets of the start of each encapsulated bundle (after the first
   bundle) in the payload field (if more than one bundle is
   encapsulated), and forwarding this new encapsulating bundle.  The
   details of the processing steps that must occur and the values that
   must be placed in the fields of various blocks of the encapsulating
   bundle are described in section 3.1 below.

   Upon receipt of a bundle that has a Bundle-in-Bundle Encapsulation
   block at a node that is a member of the destination EID of the
   bundle, the bundle is delivered to the application-specific element
   of the destination node that is responsible for bundle de-
   encapsulation.  This application-specific element extracts the
   bundle(s) from the encapsulating bundle's payload field and directs
   the bundle protocol agent to process each of these bundle(s) as if it
   had just been received from another node.  Again, the details of the
   processing steps that must occur are described in section 3.2 below.

3.1.  Generation and Transmission of an Encapsulating Bundle

   To take a bundle (or bundles) and forward this bundle(s) within the
   payload field of another bundle, a node must perform the following
   steps:

      The node SHALL process the bundle(s) for forwarding as if it were
      going to simply forward the bundle(s).  Some of the processing
      steps include, for example:

         -Processing the security extension blocks [5] (if any)
         contained in the bundle, as appropriate (e.g., verifying the
         security result in the Bundle Authentication Block and deleting
         this block, verifying the security result in the Payload
         Security Block if the node is the security destination, etc.).

         -Deleting all Previous Hop Insertion Blocks from the bundle (if
         any).

         -If the bundle should (according to local policy) be given one
         or more Previous Hop Insertion Blocks [3], these blocks SHALL
         be inserted into the bundle.




Symington, et al.          Expires May 4, 2009                  [Page 7]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


         -Processing the Metadata Extension Blocks [4] (if any)
         contained in the bundle, as appropriate.

         -If the bundle should be given one or more security extension
         blocks such as a Bundle Authentication, Payload Security, or
         Confidentiality Block, the appropriate security blocks SHALL be
         inserted into the bundle.  If the bundle is given a BAB [5],
         the EID of the node that is creating this BAB MUST be
         identified within the bundle, either through an EID reference
         to the BAB security-source or using another mechanism, such as
         the Previous Hop Insertion Block [3].  This EID must be present
         in the bundle because it will not be possible for the bundle
         protocol agent that is responsible for validating the security
         result in the BAB to determine the EID of this BAB-creating
         node through implementation-specific means (such as from the
         convergence layer).

      Next, the node's bundle protocol agent MUST direct the
      administrative element of the node's application agent to
      construct a new, encapsulating bundle.  The bundle or bundles to
      be encapsulated MUST be placed in the payload field of the
      encapsulating bundle's Bundle Payload Block.  The encapsulating
      bundle must be given a Bundle-in-Bundle Encapsulation Block.  If
      more than one bundle has been placed in the encapsulating bundle's
      payload field, the Bundle-in-Bundle Encapsulation Block must have
      a Number of Encapsulated Bundles field that has as its value the
      number of bundles that have been placed in the encapsulating
      bundle's payload field and the Bundle-in-Bundle Encapsulation
      Block must have a Bundle Offsets List field that has as its value
      the list of offsets of each of the encapsulated bundles, after the
      first encapsulated bundle, in the payload field.

      If more than one bundle is to be placed in the encapsulating
      bundle's payload field, all of these bundles must have the same
      value for their "Custody transfer is requested" Bundle Processing
      Control Flag [2].  The value of the encapsulating bundle's
      "Custody transfer is requested" Bundle Processing Control Flag
      must be set to the same value as that of the bundle(s) to be
      encapsulated.

      The value of the destination EID in the new, encapsulating bundle
      MUST be set to an endpoint ID of which the node(s) that will be
      de-encapsulating the bundle is/are a member.

      The value of the source EID of the encapsulating bundle MUST be
      set to an endpoint ID of which the node that created the
      encapsulating bundle is a member.




Symington, et al.          Expires May 4, 2009                  [Page 8]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


      The value of the Creation Timestamp of the encapsulating bundle
      MUST be set to the time at which the node began constructing the
      encapsulating bundle, and the value of the Lifetime of the
      encapsulating bundle MUST be set such that the encapsulating
      bundle will expire at or later than the expiration time of all of
      its encapsulated bundle(s).  That is, the creation time plus the
      lifetime of the encapsulating bundle must be greater than or equal
      to the creation time plus the lifetime of each of the bundles that
      have been placed in the encapsulating bundle's payload field.

      Other fields of this new, encapsulating bundle (remaining Bundle
      Processing Control Flag values, Block Length, Dictionary byte
      array, etc.) must be given appropriate values.

      Once this new, encapsulating bundle has been constructed, it SHALL
      be processed for forwarding (i.e., given security blocks, given a
      Previous Hop Insertion Block, given a Metadata Extension Block,
      etc. as appropriate) and then forwarded.

      Note that there is currently no Bundle Status Report Status Flag
      [2] defined to indicate that the "Reporting node is encapsulating
      a bundle".  Such a status report could possibly be helpful and
      perhaps should be defined in the future.  If such a status report
      were to be sent to the current custodian (if any) of the
      encapsulated bundle upon its encapsulation, for example, the
      status report would indicate to the custodian that custody signals
      for the encapsulated bundle will not be received until some time
      after the encapsulated bundle has been de-encapsulated.

3.2.  Receipt and Processing of an Encapsulating Bundle

   Upon delivery of a bundle that has a Bundle-in-Bundle Encapsulation
   Block and, therefore, a payload field that consists of one or more
   encapsulated bundles, the application-specific element of the
   application agent of the node at which the bundle was delivered SHALL
   perform the following processing steps:

      Extract the encapsulated bundle(s) from the encapsulating bundle's
      payload field.

      Pass each of these de-encapsulated bundles in their entirety to
      the node's bundle protocol agent.

   Upon receipt of each of these de-encapsulated bundles, the bundle
   protocol agent SHALL process each bundle as if it had just been
   received from another node.  It will not be possible for the bundle
   protocol agent to determine the EID of the forwarding node of these
   de-encapsulated bundles through implementation-specific means (such



Symington, et al.          Expires May 4, 2009                  [Page 9]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


   as from the convergence layer), because the forwarding node was the
   node that provided the bundle for encapsulation, not necessarily the
   node from which the encapsulating bundle was received.  Therefore, if
   the EID of the forwarding node is needed by the bundle protocol
   agent, this EID MUST be present in the de-encapsulated bundle, for
   example, in a Previous Hop Insertion Block [3] or in the EID
   reference to the security-source of a BAB [5], if the bundle contains
   a BAB.  Some of the processing steps that the bundle protocol agent
   SHALL perform include, for example:

      -Processing the security extension blocks [5] (if any) contained
      in the bundle, as appropriate (e.g., verifying the security result
      in the Bundle Authentication Block and deleting this block,
      verifying the security result in the Payload Security Block if the
      node is the security destination, etc.).

      -Deleting all Previous Hop Insertion Blocks from the bundle (if
      any).

      -Processing the Metadata Extension Blocks [4](if any) contained in
      the bundle, as appropriate.

      -The bundle protocol agent SHALL deliver the bundle, if
      appropriate.

      -The bundle protocol agent SHALL perform custody transfer and/or
      status reporting procedures on the bundle as directed by the
      bundle's custody transfer and status report request flags.

      -If the bundle should (according to local policy) be given one or
      more Previous Hop Insertion Blocks [3], these blocks SHALL be
      inserted into the bundle.

      -If the bundle should be given one or more security extension
      blocks such as a Bundle Authentication, Payload Security, or
      Confidentiality Block, the appropriate security blocks SHALL be
      inserted into the bundle.

      -The bundle protocol agent SHALL forward the bundle to all
      appropriate endpoints.











Symington, et al.          Expires May 4, 2009                 [Page 10]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


4.  Security Considerations

   There are two documents that pertain to providing security within the
   DTN Bundle Protocol: [5] and [7].

   The mandatory BAB-HMAC ciphersuite defined in [5], because it uses
   the strict canonicalization algorithm that calculates a security
   result over all blocks in the bundle, can be used to detect changes
   that occur in the Bundle-in-Bundle Encapsulation Block while in
   transit between neighboring DTN nodes.

   The mandatory PIB-RSA-SHA256 ciphersuite defined in [5], however,
   cannot be used to detect changes that occur in the Bundle-in-Bundle
   Encapsulation block as it traverses multiple neighboring DTN nodes,
   because this ciphersuite uses the mutable canonicalization algorithm,
   which does not include the Bundle-in-Bundle Encapsulation Block among
   the blocks over which it calculates a security result.  In order to
   ensure the end-to-end integrity of the Bundle-in-Bundle Encapsulation
   Block, the mutable canonicalization algorithm would need to be
   modified to include the Bundle-in-Bundle Encapsulation Block among
   those blocks included in the mutable canonicalization of the bundle.

   The mandatory PCB-RSA_AES128-PAYLOAD-PIB-PCB ciphersuite defined in
   [5] will encrypt the encapsulated bundle(s) because these are stored
   in the payload field and this ciphersuite encrypts the payload field.
   However, this ciphersuite will not encrypt the Bundle-in-Bundle
   Encapsulation Block in the encapsulating bundle, so, using the
   available mandatory confidentiality ciphersuite, there is no way to
   keep confidential the fact that the bundle is an encapsulating bundle
   or the information regarding the number of bundles encapsulated and
   their offsets.  To provide confidentiality protection of this sort, a
   new ciphersuite for the Payload Confidentiality Block would have to
   be defined that includes protection of the Bundle-in-Bundle
   Encapsulation Block.

   It should be noted that when a bundle is encapsulated, the
   encapsulated bundle itself may be protected by one or more security
   blocks.  In particular, it may contain a Bundle Authentication Block
   (BAB), which is designed to be processed by a next-hop neighboring
   node.  If a bundle with a BAB is encapsulated by one node and it is
   received and de-encapsulated by a non-neighboring node, the bundle
   protocol agent to which the de-encapsulated bundle is passed for
   processing must be capable of validating the security result in the
   BAB if its security policy requires such validation.  Therefore,
   encapsulation of bundles protected by BABs may require that keys that
   are normally only shared between neighbors be distributed further in
   the DTN so that they are shared by the encapsulating and de-
   encapsulating nodes.  Furthermore, because it is not possible for the



Symington, et al.          Expires May 4, 2009                 [Page 11]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


   bundle protocol agent to which the de-encapsulated bundle is passed
   to determine the EID of the forwarding node that inserted the BAB
   into the encapsulated bundle through implementation-specific means
   (such as from the convergence layer), if the EID of this forwarding
   node is not identified elsewhere in the encapsulated bundle (e.g. in
   the Previous Hop Insertion Block), this EID must be present in the
   security-source field of the BAB.












































Symington, et al.          Expires May 4, 2009                 [Page 12]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


5.  IANA Considerations

   None at this time.  If the bundle protocol becomes a standards track
   protocol, then we may want to consider having IANA establish a
   register of extension block types, of which the Bundle-in-Bundle
   Encapsulation Block would be one.













































Symington, et al.          Expires May 4, 2009                 [Page 13]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


6.  References

6.1.  Normative References

   [1]  Bradner, S. and J. Reynolds, "Key words for use in RFCs to
        Indicate Requirement Levels", RFC 2119, October 1997.

   [2]  Scott, K. and S. Burleigh, "Bundle Protocol Specification",
        RFC, 5050, November 2007.

   [3]  Symington, S., "Delay-Tolerant Networking Previous Hop Insertion
        Block", draft-irtf-dtnrg-bundle-previous-hop-block-04.txt, work-
        in-progress, September 2008.

   [4]  Symington, S., "Delay-Tolerant Networking Metadata Extension
        Block",
        draft-irtf-dtnrg-bundle-metadata-block-00.txt, work-in-progress,
        September 2008.

   [5]  Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle
        Security Protocol Specification",
        draft-irtf-dtnrg-bundle-security-06.txt, work-in-progress,
        November 2008.

6.2.  Informative References

   [6]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R.,
        Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network
        Architecture", RFC 4838, April 2007.

   [7]  Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay-
        Tolerant Network Security Overview",
        draft-irtf-dtnrg-sec-overview-05.txt, work-in-progress,
        November 2008.

















Symington, et al.          Expires May 4, 2009                 [Page 14]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


Authors' Addresses

   Susan Flynn Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-7209
   Email: susan@mitre.org
   URI:   http://mitre.org/


   Robert C. Durst
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-7535
   Email: durst@mitre.org
   URI:   http://mitre.org/


   Keith L. Scott
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-6547
   Email: kscott@mitre.org
   URI:   http://mitre.org/


















Symington, et al.          Expires May 4, 2009                 [Page 15]

Internet-Draft     DTN Bundle-in-Bundle Encapsulation       October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Symington, et al.          Expires May 4, 2009                 [Page 16]