idnits 2.17.1 draft-tsuchiya-encap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 1991) is 11814 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Tsuchiya 3 INTERNET-DRAFT Bellcore 4 December 1991 6 Mutual Encapsulation Considered Dangerous 8 Status of this Memo 10 This memo describes a packet explosion problem that can occur with 11 mutual encapsulation of protocols (A encapsulates B and B 12 encapsulates A). This memo is purely informational. 14 The Current Environment 16 In spite of international standardization efforts to the contrary, we 17 are these days seeing a plethora of different protocols, both 18 standard and proprietary, each designed to fill a technical or 19 marketing niche. The end result is that they eventually butt up 20 against each other and are expected to interwork in some fashion. 22 One approach to this interworking is to encapsulate one protocol 23 within another. This has resulted in cases of mutual encapsulation, 24 where protocol A runs over protocol B in some cases, and protocol B 25 runs over protocol A in other cases. For example, there exists cases 26 of both IP over AppleTalk and AppleTalk over IP. (The term mutual 27 encapsulation comes from the paper by Shoch, Cohen, and Taft, called 28 "Mutual Encapsulation of Internetwork Protocols", Computer Networks 29 5, North-Holland, 1981, 287-300. The problem identified in this RFC 30 is not mentioned in the Shoch et. al. paper.) 32 If there are not already other instances of mutual encapsulation, 33 there will likely be more in the future. This is particularly true 34 with respect to the various internet protocols, such as IP, CLNP, 35 AppleTalk, IPX, DECNET, and so on. 37 The Problem 39 The problem with mutual encapsulation is the following. Consider the 40 topology shown in Figure 1. We see two backbones and four stubs. 41 Backbone B(X) uses a native protocol of X (that is, it expects to 42 receive packets with a header for protocol X). B(Y) uses a native 43 protocol of Y. Likewise, the right and left S(Y) stubs use protocol 44 Y, and the right and left S(X) stubs use protocol X. 46 ::: ::::: ::::: ::: ::: 47 +------+ :Y :X:Y +------+ :X:Y :Y +------+ :Y +------+ 48 | | ::: ::::: | | ::::: ::: | | ::: | | 49 | S(Y) |-----Ra-----| |-------Rb----| |------| S(Y) | 50 | | | | | | | | 51 +------+ | | | | +------+ 52 | B(X) | | B(Y) | 53 | | | | 54 ::: | | ::: ::::: | | ::::: ::: 55 +------+ X: | | X: X:Y: | | X:Y: X: +------+ 56 | | ::: | | ::: ::::: | | ::::: ::: | | 57 | S(X) |------| |-----Rc------| |------Rd----| S(X) | 58 | | | | | | | | 59 +------+ | |-----Re------| | +------+ 60 +------+ +------+ 62 LEGEND: 64 ::::: 65 X:Y: A packet with protocol X encapsulated in protocol 66 ::::: Y, moving left to right 68 Rx Router x 70 S(Y) A stub network whose native protocol is protocol Y 72 B(X) A backbone network whose native protocol is protocol X 74 FIGURE 1: MUTUAL ENCAPSULATION 76 Figure 1 shows how packets would travel from left S(X) to right S(X), 77 and from right S(Y) to left S(Y). Consider a packet from left S(X) 78 to right S(X). The packet from left S(X) has just a header of X up 79 to the point where it reaches router Rc. Since B(Y) cannot forward 80 header X, Rc encapsulates the packet into a Y header with a 81 destination address of Rd. When Rd receives the packet from B(Y), it 82 strips off the Y header and forwards the X header packet to right 83 S(X). The reverse situation exists for packets from right S(Y) to 84 left S(Y). 86 In this example Rc and Rd treat B(Y) as a lower-level subnetwork in 87 exactly the same way that an IP router currently treats an Ethernet 88 as a lower-level subnetwork. Note that Rc considers Rd to be the 89 appropriate "exit router" for packets destined for right S(X), and Rb 90 considers Ra to be the appropriate "exit router" for packets destined 91 for left S(Y). 93 Now, assume that somehow a routing loop forms such that routers in 94 B(Y) think that Rd is reachable via Rb, Rb thinks that Rd is 95 reachable via Re, and routers in B(X) think that Re is reachable via 96 Rc. (This could result as a transient condition in the routing 97 algorithm if Rd and Re crashed at the same time.) When the initial 98 packet from left S(X) reaches Rc, it is encapsulated with Y and sent 99 to B(Y), which forwards it onto Rb. (The notation for this packet is 100 Y, meaning that X in encapsulated in Y.) 102 When Rb receives Y from B(Y), it encapsulates the packet in an X 103 header to get it to Re through B(X). Now the packet has headers 104 X>. In other words, the packet has two X encapsulates. When Rc 105 receives X>, it again encapsulates the packet, resulting in 106 Y>>. The packet is growing with each encapsulation. 108 Now, if we assume that each successive encapsulation does not 109 preserve the hop count information in the previous header, then the 110 packet will never expire. Worse, the packet will eventually reach 111 the Maximum Transmission Unit (MTU) size, and will fragment. Each 112 fragment will continue around the loop, getting successively larger 113 until those fragments also fragment. The result is an exponential 114 explosion in the number of looping packets! 116 The explosion will persist until the links are saturated, and the 117 links will remain saturated until the loop is broken. If the looping 118 packets dominate the link to the point where other packets, such as 119 routing update packets or management packets, are thrown away, then 120 the loop may not automatically break itself, thus requiring manual 121 intervention. Once the loop is broken, the packets will quickly be 122 flushed from the network. 124 Potential Fixes 126 The first potential fix that comes to mind is to always preserve the 127 hop count information in the new header. Since hop count information 128 is preserved in fragments, the explosion will not occur even if some 129 fragmentation occurs before the hop count expires. Not all headers, 130 however, have hop count information in them (for instance, X.25 and 131 SMDS). 133 And the hop counts ranges for different protocols are different, 134 making direct translation not always possible. For instance, 135 AppleTalk has a maximum hop count of 16, whereas IP has up to 256. 136 One could define a mapping whereby the hop count is lowered to fit 137 into the smaller range when necessary. This, however, might often 138 result in unnecessary black holes because of overly small hop counts. 139 There are for instance many IP paths that are longer than 16 hops. 141 It is worth noting that the current IP over AppleTalk Internet Draft 142 does not preserve hop counts ("A Standard for the Transmission of 143 Internet Packets Over AppleTalk Networks"). 145 Another potential fix is to have routers peek into network layer 146 headers to see if the planned encapsulation already exists. For 147 instance, in the example of Figure 1, when Rb receives Y, it would 148 see what Y had encapsulated (for instance by looking at the protocol 149 id field of X's header), notice that X has already been encapsulated, 150 and throw away the packet. If the encapsulation loop involves more 151 than two protocols, then the router may have to peek into successive 152 network layer headers. It would quit when it finally got to a 153 transport layer header. 155 There are several pitfalls with this approach. First, it is always 156 possible that a network layer protocol is being encapsulated within a 157 transport layer protocol, thus I suppose requiring that the router 158 continue to peek even above the transport layer. 160 Second, the router may not recognize one of the network layer 161 headers, thus preventing it from peeking any further. For instance, 162 consider a loop involving three routers Rxy, Ryz, and Rzx, and three 163 protocols X, Y, and Z (the subscripts on the routers R denote which 164 protocols the router recognizes). After the first loop, Rxy receives 165 X>>. Since Rxy does not recognize Z, it cannot peek beyond Z 166 to discover the embedded Y header. 168 Third, a router may be encrypting the packet that it sends to its 169 peer, such as is done with Blacker routers. For instance, Rc might 170 be encrypting packets that it encapsulates for Rd, expecting Rd to 171 decrypt it. When Rb receives this packet (because of the loop), it 172 cannot peek beyond the Y header. 174 Finally, there may be situations where it is appropriate to have 175 multiple instances of the same header. For instance, in the nested 176 mutual encapsulation of Figure 2, Ra will encapsulate Y in X to get 177 it to Rd, but Rb will encapsulate X in Y to get it to Rc. In this 178 case, it is appropriate for Rb to transmit a packet with two Y 179 headers. 181 A third (somewhat hybrid) solution is to outlaw nested mutual 182 encapsulation, employ both hop count preservation and header peeking 183 where appropriate, and generally discourage the use of mutual 184 encapsulation (or at least adopt the attitude that those who engage 185 in mutual encapsulation deserve what they get). 187 +--------------------+ 188 | | 189 | B(X) | 190 +------+ | +------+ | +------+ 191 | | | | | | | | 192 | S(Y) |--Ra--+ Rb-| B(Y) |-Rc +--Rd--| S(Y) | 193 | | | | | | | | 194 +------+ | +------+ | +------+ 195 | | 196 | | 197 +--------------------+ 199 FIGURE 2: NESTED MUTUAL ENCAPSULATION 201 Security Considerations 203 Security issues are not discussed in this memo. 205 Author's Address 207 Paul Tsuchiya 208 Bellcore 209 435 South St. 2L-281 210 Morristown, NJ, 07960 212 Phone: (908) 829-4484 214 EMail: tsuchiya@thumper.bellcore.com