home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1326 < prev    next >
Text File  |  1992-05-15  |  11KB  |  283 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        P. Tsuchiya
  8. Request for Comments: 1326                                      Bellcore
  9.                                                                 May 1992
  10.  
  11.  
  12.                Mutual Encapsulation Considered Dangerous
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This memo describes a packet explosion problem that can occur with
  23.    mutual encapsulation of protocols (A encapsulates B and B
  24.    encapsulates A).
  25.  
  26. The Current Environment
  27.  
  28.    In spite of international standardization efforts to the contrary, we
  29.    are these days seeing a plethora of different protocols, both
  30.    standard and proprietary, each designed to fill a technical or
  31.    marketing niche.  The end result is that they eventually butt up
  32.    against each other and are expected to interwork in some fashion.
  33.  
  34.    One approach to this interworking is to encapsulate one protocol
  35.    within another.  This has resulted in cases of mutual encapsulation,
  36.    where protocol A runs over protocol B in some cases, and protocol B
  37.    runs over protocol A in other cases.  For example, there exists cases
  38.    of both IP over AppleTalk and AppleTalk over IP.  (The term mutual
  39.    encapsulation comes from the paper by Shoch, Cohen, and Taft, called
  40.    Mutual Encapsulation of Internetwork Protocols", Computer Networks 5,
  41.    North-Holland, 1981, 287-300.  The problem identified in this RFC is
  42.    not mentioned in the Shoch et. al. paper.)
  43.  
  44.    If there are not already other instances of mutual encapsulation,
  45.    there will likely be more in the future.  This is particularly true
  46.    with respect to the various internet protocols, such as IP, CLNP,
  47.    AppleTalk, IPX, DECNET, and so on.
  48.  
  49. The Problem
  50.  
  51.    The problem with mutual encapsulation is the following.  Consider the
  52.    topology shown in Figure 1.  We see two backbones and four stubs.
  53.    Backbone B(X) uses a native protocol of X (that is, it expects to
  54.    receive packets with a header for protocol X).  B(Y) uses a native
  55.  
  56.  
  57.  
  58. Tsuchiya                                                        [Page 1]
  59.  
  60. RFC 1326                Encapsulation Dangerous                 May 1992
  61.  
  62.  
  63.    protocol of Y.  Likewise, the right and left S(Y) stubs use protocol
  64.    Y, and the right and left S(X) stubs use protocol X.
  65.  
  66.           :::  :::::          :::::   :::          :::
  67.  +------+ :Y   :X:Y  +------+ :X:Y    :Y  +------+ :Y   +------+
  68.  |      | :::  ::::: |      | :::::   ::: |      | :::  |      |
  69.  | S(Y) |-----Ra-----|      |-------Rb----|      |------| S(Y) |
  70.  |      |            |      |             |      |      |      |
  71.  +------+            |      |             |      |      +------+
  72.                      | B(X) |             | B(Y) |
  73.                      |      |             |      |
  74.                 :::  |      | :::   ::::: |      | :::::  :::
  75.        +------+  X:  |      |  X:    X:Y: |      |  X:Y:   X: +------+
  76.        |      | :::  |      | :::   ::::: |      | :::::  ::: |      |
  77.        | S(X) |------|      |-----Rc------|      |------Rd----| S(X) |
  78.        |      |      |      |             |      |            |      |
  79.        +------+      |      |-----Re------|      |            +------+
  80.                      +------+             +------+
  81.  
  82.  
  83.    LEGEND:
  84.  
  85.         :::::
  86.          X:Y:  A packet with protocol X encapsulated in protocol
  87.         :::::  Y, moving left to right
  88.  
  89.            Rx  Router x
  90.  
  91.          S(Y)  A stub network whose native protocol is protocol Y
  92.  
  93.          B(X)  A backbone network whose native protocol is protocol X
  94.  
  95.  
  96.              FIGURE 1:  MUTUAL ENCAPSULATION
  97.  
  98.    Figure 1 shows how packets would travel from left S(X) to right S(X),
  99.    and from right S(Y) to left S(Y).  Consider a packet from left S(X)
  100.    to right S(X).  The packet from left S(X) has just a header of X up
  101.    to the point where it reaches router Rc.  Since B(Y) cannot forward
  102.    header X, Rc encapsulates the packet into a Y header with a
  103.    destination address of Rd.  When Rd receives the packet from B(Y), it
  104.    strips off the Y header and forwards the X header packet to right
  105.    S(X).  The reverse situation exists for packets from right S(Y) to
  106.    left S(Y).
  107.  
  108.    In this example Rc and Rd treat B(Y) as a lower-level subnetwork in
  109.    exactly the same way that an IP router currently treats an Ethernet
  110.    as a lower-level subnetwork.  Note that Rc considers Rd to be the
  111.  
  112.  
  113.  
  114. Tsuchiya                                                        [Page 2]
  115.  
  116. RFC 1326                Encapsulation Dangerous                 May 1992
  117.  
  118.  
  119.    appropriate "exit router" for packets destined for right S(X), and Rb
  120.    considers Ra to be the appropriate "exit router" for packets destined
  121.    for left S(Y).
  122.  
  123.    Now, assume that somehow a routing loop forms such that routers in
  124.    B(Y) think that Rd is reachable via Rb, Rb thinks that Rd is
  125.    reachable via Re, and routers in B(X) think that Re is reachable via
  126.    Rc.  (This could result as a transient condition in the routing
  127.    algorithm if Rd and Re crashed at the same time.) When the initial
  128.    packet from left S(X) reaches Rc, it is encapsulated with Y and sent
  129.    to B(Y), which forwards it onto Rb.  (The notation for this packet is
  130.    Y<X>, meaning that X in encapsulated in Y.)
  131.  
  132.    When Rb receives Y<X> from B(Y), it encapsulates the packet in an X
  133.    header to get it to Re through B(X).  Now the packet has headers
  134.    X<Y<X>>.  In other words, the packet has two X encapsulates.  When Rc
  135.    receives X<Y<X>>, it again encapsulates the packet, resulting in
  136.    Y<X<Y<X>>>.  The packet is growing with each encapsulation.
  137.  
  138.    Now, if we assume that each successive encapsulation does not
  139.    preserve the hop count information in the previous header, then the
  140.    packet will never expire.  Worse, the packet will eventually reach
  141.    the Maximum Transmission Unit (MTU) size, and will fragment.  Each
  142.    fragment will continue around the loop, getting successively larger
  143.    until those fragments also fragment.  The result is an exponential
  144.    explosion in the number of looping packets!
  145.  
  146.    The explosion will persist until the links are saturated, and the
  147.    links will remain saturated until the loop is broken.  If the looping
  148.    packets dominate the link to the point where other packets, such as
  149.    routing update packets or management packets, are thrown away, then
  150.    the loop may not automatically break itself, thus requiring manual
  151.    intervention.  Once the loop is broken, the packets will quickly be
  152.    flushed from the network.
  153.  
  154. Potential Fixes
  155.  
  156.    The first potential fix that comes to mind is to always preserve the
  157.    hop count information in the new header.  Since hop count information
  158.    is preserved in fragments, the explosion will not occur even if some
  159.    fragmentation occurs before the hop count expires.  Not all headers,
  160.    however, have hop count information in them (for instance, X.25 and
  161.    SMDS).
  162.  
  163.    And the hop counts ranges for different protocols are different,
  164.    making direct translation not always possible.  For instance,
  165.    AppleTalk has a maximum hop count of 16, whereas IP has up to 256.
  166.    One could define a mapping whereby the hop count is lowered to fit
  167.  
  168.  
  169.  
  170. Tsuchiya                                                        [Page 3]
  171.  
  172. RFC 1326                Encapsulation Dangerous                 May 1992
  173.  
  174.  
  175.    into the smaller range when necessary.  This, however, might often
  176.    result in unnecessary black holes because of overly small hop counts.
  177.    There are for instance many IP paths that are longer than 16 hops.
  178.  
  179.    It is worth noting that the current IP over AppleTalk Internet Draft
  180.    does not preserve hop counts ("A Standard for the Transmission of
  181.    Internet Packets Over AppleTalk Networks").
  182.  
  183.    Another potential fix is to have routers peek into network layer
  184.    headers to see if the planned encapsulation already exists.  For
  185.    instance, in the example of Figure 1, when Rb receives Y<X>, it would
  186.    see what Y had encapsulated (for instance by looking at the protocol
  187.    id field of X's header), notice that X has already been encapsulated,
  188.    and throw away the packet.  If the encapsulation loop involves more
  189.    than two protocols, then the router may have to peek into successive
  190.    network layer headers.  It would quit when it finally got to a
  191.    transport layer header.
  192.  
  193.    There are several pitfalls with this approach.  First, it is always
  194.    possible that a network layer protocol is being encapsulated within a
  195.    transport layer protocol, thus I suppose requiring that the router
  196.    continue to peek even above the transport layer.
  197.  
  198.    Second, the router may not recognize one of the network layer
  199.    headers, thus preventing it from peeking any further.  For instance,
  200.    consider a loop involving three routers Rxy, Ryz, and Rzx, and three
  201.    protocols X, Y, and Z (the subscripts on the routers R denote which
  202.    protocols the router recognizes).  After the first loop, Rxy receives
  203.    X<Z<Y<X>>>.  Since Rxy does not recognize Z, it cannot peek beyond Z
  204.    to discover the embedded Y header.
  205.  
  206.    Third, a router may be encrypting the packet that it sends to its
  207.    peer, such as is done with Blacker routers.  For instance, Rc might
  208.    be encrypting packets that it encapsulates for Rd, expecting Rd to
  209.    decrypt it.  When Rb receives this packet (because of the loop), it
  210.    cannot peek beyond the Y header.
  211.  
  212.    Finally, there may be situations where it is appropriate to have
  213.    multiple instances of the same header.  For instance, in the nested
  214.    mutual encapsulation of Figure 2, Ra will encapsulate Y in X to get
  215.    it to Rd, but Rb will encapsulate X<Y> in Y to get it to Rc.  In this
  216.    case, it is appropriate for Rb to transmit a packet with two Y
  217.    headers.
  218.  
  219.    A third (somewhat hybrid) solution is to outlaw nested mutual
  220.    encapsulation, employ both hop count preservation and header peeking
  221.    where appropriate, and generally discourage the use of mutual
  222.    encapsulation (or at least adopt the attitude that those who engage
  223.  
  224.  
  225.  
  226. Tsuchiya                                                        [Page 4]
  227.  
  228. RFC 1326                Encapsulation Dangerous                 May 1992
  229.  
  230.  
  231.    in mutual encapsulation deserve what they get).
  232.  
  233.                      +--------------------+
  234.                      |                    |
  235.                      |               B(X) |
  236.        +------+      |      +------+      |      +------+
  237.        |      |      |      |      |      |      |      |
  238.        | S(Y) |--Ra--+   Rb-| B(Y) |-Rc   +--Rd--| S(Y) |
  239.        |      |      |      |      |      |      |      |
  240.        +------+      |      +------+      |      +------+
  241.                      |                    |
  242.                      |                    |
  243.                      +--------------------+
  244.  
  245.                 FIGURE 2:  NESTED MUTUAL ENCAPSULATION
  246.  
  247. Security Considerations
  248.  
  249.    Security issues are not discussed in this memo.
  250.  
  251. Author's Address
  252.  
  253.    Paul Tsuchiya
  254.    Bellcore
  255.    435 South St.
  256.    MRE 2L-281
  257.    Morristown, NJ 07960
  258.  
  259.    Phone: (908) 829-4484
  260.    EMail:  tsuchiya@thumper.bellcore.com
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Tsuchiya                                                        [Page 5]
  283.