performed at one IPsec instance at the (ultimate)
             destination.

             Host 1 --- Security ---- Internet -- Security --- Host 2
              | |        Gwy 1                      Gwy 2        | |
              | |                                                | |
              | -----Security Association 1 (ESP transport)------- |
              |                                                    |
              -------Security Association 2 (AH transport)----------

           o Iterated tunneling refers to the application of multiple
             layers of security protocols effected through IP tunneling.
             This approach allows for multiple levels of nesting, since
             each tunnel can originate or terminate at a different IPsec




 
RFC 2401              Security Architecture for IP         November 1998


             site along the path.  No special treatment is expected for
             ISAKMP traffic at intermediate security gateways other than
             what can be specified through appropriate SPD entries (See
             Case 3 in Section 4.5)

             There are 3 basic cases of iterated tunneling -- support is
             required only for cases 2 and 3.:

             1. both endpoints for the SAs are the same -- The inner and
                outer tunnels could each be either AH or ESP, though it
                is unlikely that Host 1 would specify both to be the
                same, i.e., AH inside of AH or ESP inside of ESP.

                Host 1 --- Security ---- Internet -- Security --- Host 2
                 | |        Gwy 1                      Gwy 2        | |
                 | |                                                | |
                 | -------Security Association 1 (tunnel)---------- | |
                 |                                                    |
                 ---------Security Association 2 (tunnel)--------------

             2. one endpoint of the SAs is the same -- The inner and
                uter tunnels could each be either AH or ESP.

                Host 1 --- Security ---- Internet -- Security --- Host 2
                 | |        Gwy 1                      Gwy 2         |
                 | |                                     |           |
                 | ----Security Association 1 (tunnel)----           |
                 |                                                   |
                 ---------Security Association 2 (tunnel)-------------

             3. neither endpoint is the same -- The inner and outer
                tunnels could each be either AH or ESP.

                Host 1 --- Security ---- Internet -- Security --- Host 2
                 |          Gwy 1                      Gwy 2         |
                 |            |                          |           |
                 |            --Security Assoc 1 (tunnel)-           |
                 |                                                   |
                 -----------Security Association 2 (tunnel)-----------

   These two approaches also can be combined, e.g., an SA bundle could
   be constructed from one tunnel mode SA and one or two transport mode
   SAs, applied in sequence.  (See Section 4.5 "Basic Combinations of
   Security Associations.") Note that nested tunnels can also occur
   where neither the source nor the destination endpoints of any of the
   tunnels are the same.  In that case, there would be no host or
   security gateway with a bundle corresponding to the nested tunnels.





 
RFC 2401              Security Architecture for IP         November 1998


   For transport mode SAs, only one ordering of security protocols seems
   appropriate.  AH is applied to both the upper layer protocols and
   (parts of) the IP header.  Thus if AH is used in a transport mode, in
   conjunction with ESP, AH SHOULD appear as the first header after IP,
   prior to the appearance of ESP.  In that context, AH is applied to
   the ciphertext output of ESP.  In contrast, for tunnel mode SAs, one
   can imagine uses for various orderings of AH and ESP.  The required
   set of SA bundle types that MUST be supported by a compliant IPsec
   implementation is described in Section 4.5.

4.4 Security Association Databases

   Many of the details associated with processing IP traffic in an IPsec
   implementation are largely a local matter, not subject to
   standardization.  However, some external aspects of the processing
   must be standardized, to ensure interoperability and to provide a
   minimum management capability that is essential for productive use of
   IPsec.  This section describes a general model for processing IP
   traffic relative to security associations, in support of these
   interoperability and functionality goals.  The model described below
   is nominal; compliant implementations need not match details of this
   model as presented, but the external behavior of such implementations