idnits 2.17.1 draft-freed-firewall-req-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 387 has weird spacing: '...rnished to ot...' == Line 388 has weird spacing: '...herwise expla...' == Line 390 has weird spacing: '...without restr...' == Line 391 has weird spacing: '... notice and t...' == Line 392 has weird spacing: '...ivative works...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1997) is 9629 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) ** Obsolete normative reference: RFC 1830 (ref. '2') (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 821 (ref. '5') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '6') (Obsoleted by RFC 2822) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed, Innosoft 3 Kevin Carosso, Innosoft 4 Internet Draft 6 An Internet Firewall 7 Transparency Requirement 9 December 1997 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress". 25 To learn the current status of any Internet-Draft, please 26 check the 1id-abstracts.txt listing contained in the 27 Internet-Drafts Shadow Directories on ds.internic.net (US East 28 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 29 or munnari.oz.au (Pacific Rim). 31 Copyright (C) The Internet Society (1997). All Rights 32 Reserved. 34 1. Abstract 36 This memo defines a basic transparency requirement for 37 Internet firewalls. While such a requirement may seem 38 obvious, the fact of the matter is that firewall behavior is 39 currently either unspecified or underspecified, and this lack 40 of specificity often causes problems in practice. This 41 requirement is intended to be a necessary first step in making 42 the behavior of firewalls more consistent and correct. 44 2. Introduction 46 The Internet is now being used for an increasing number of 47 mission critical applications. Because of this many sites find 48 isolated secure intranets insufficient for their needs, even 49 when those intranets are based on and use Internet protocols. 50 Instead they find it necessary to provide direct 51 communications paths between the unsecured and sometimes 52 hostile Internet and systems or networks which either deal 53 with valuable data, provide vital services, or both. 55 The security concerns that inevitably arise from such setups 56 are often dealt with by inserting one or more "firewalls" on 57 the path between the Internet and the internal network. A 58 "firewall" is an agent which screens network traffic in some 59 way, blocking traffic it believes to inappropriate, dangerous, 60 or both. 62 More specifically, firewalls either act as a protocol end 63 point (e.g. a SMTP client/server or a Web proxy agent), as a 64 packet filter, or some combination of both. 66 When a firewall acts a protocol end point it may 68 (1) implement a "safe" subset of the protocol, 70 (2) perform extensive protocol validity checks, 72 (3) use an implementation methodology designed to minimize 73 the liklihood of bugs, 75 (4) run in an insolated, "safe" environment, or 77 (5) use some combination of these techniques in tandem. 79 In the case of a packet filter the firewall isn't visible as a 80 protocol end point. Each packet is examined and the firewall 81 may then 83 (1) pass the packet through to the other side unchanged, 85 (2) drop the packet entirely, or 87 (3) handle the packet itself in some way. 89 Firewalls typically base some of their decisions on IP source 90 and destination addresses and port numbers. For example, 91 firewalls may 93 (1) block packets from the Internet side that claim a 94 source address of a system on the internal network, 96 (2) block TELNET or RLOGIN connections from the Internet to 97 the internal network, 99 (3) block SMTP and FTP connections to the Internet from 100 internal systems not authorized to send email or move 101 files, 103 (4) act as an intermediate server in handling SMTP and HTTP 104 connections in either direction, or 106 (5) require the use of an access negotiation and 107 encapsulation protocol like SOCKS [1] to gain access to 108 the Internet, to the internal network, or both. 110 (This list is only intended to illustrate the sorts of things 111 firewalls often do; it is by no means exhaustive, nor are all 112 firewall products able to perform all the operations on this 113 list.) 115 Unfortunately, the development and deployment of firewalls has 116 for the most part been ignored by the Internet standards 117 community. As a result of this inattention the use of 118 firewalls has solved some old problems, but not without 119 generating lots of new ones in the process. 121 This memo is intended to address the new problems firewalls 122 can cause by establishing a basic transparency requirement for 123 firewalls. 125 2.1. Requirements notation 127 This document occasionally uses terms that appear in capital 128 letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD 129 NOT", and "MAY" appear capitalized, they are being used to 130 indicate particular requirements of this specification. A 131 discussion of the meanings of these terms appears in RFC 2119 132 [3]. 134 3. The Transparency Requirement 136 The basic transparency requirement for firewalls is quite 137 simple: 139 The introduction of a firewall and any associated 140 tunneling or access negotiation facilities MUST NOT cause 141 the gratuitous failure of legitimate and standards- 142 compliant usage that would work were the firewall not 143 present. 145 A necessary corollary to this requirement is that when such 146 failures do occur it is incumbent on the firewall and 147 associated software to address the problem: Changes to either 148 implementations of existing standard protocols or the 149 protocols themselves MUST NOT be necessary. 151 Note that this requirement only applies to legitimate protocol 152 usage and gratuitous faiures -- a firewall is entitled to 153 block any sort of access that is seen as illegitimate, 154 regardless of whether or not it is standards-compliant. This 155 is, after all, the primary reason to have a firewall in the 156 first place. 158 4. Security Considerations 160 The transparency rule impacts security to the extent that it 161 precludes certain simpleminded firewall implementation 162 techniques. Firewall implementors must therefore work a little 163 harder to achieve a given level of security. However, the 164 transparency rule in no way prevents an implementor from 165 achieving whatever level of security is necessary. Moreover, a 166 little more work up front results in better security in the 167 long run because techniques that do not interfere with 168 existing services will almost certainly be more widely 169 deployed than ones that do interfere and prevent people from 170 performing useful work. 172 Now, some firewall implementors will inevitably claim that the 173 burden of total transparency is overly onerous and that 174 adequate security cannot be achieved in the face of such a 175 requirement. And there's no question that meeting the 176 transparency requirement is more difficult than not doing so. 178 Nevertheless, it is important to remember that the only 179 perfectly secure network is one that doesn't allow any data 180 through at all, and that the only problem with such a network 181 is that it is unusable. Anything less is necessarily a 182 tradeoff between useability and security. And the simple fact 183 of the matter is that at present firewalls are being 184 circumvented in ad hoc ways, necessarily weakening security 185 dramatically, simply because they don't meet this transparency 186 requirement. In other words, the only reason that some 187 firewalls remain in use is because they have essentially been 188 disabled. As such, one reason to have a transparency 189 requirement is to IMPROVE security. 191 Good security may occasionallly result in interoperability 192 failures between components. This is understood. However, this 193 doesn't mean that gratiutous interoperability failures caused 194 by security components are acceptable. They aren't. 196 5. Example Violations of the Transparency Rule 198 This document will conclude with a (long) list of existing 199 firewall behavior that violates the transparency requirement. 201 (1) In an effort to enhance security by hiding internal 202 system names that might otherwise be revealed in email 203 headers, some firewalls either strip information from 204 or completely delete certain header fields. There are 205 even known cases of certain text strings (e.g. names of 206 internal hosts systems) being deleted from message 207 bodies. 209 Blindly deleting information from message body text is 210 simply not acceptable. Consider what happens when a 211 string is deleted from a binary part encoded in base64 212 simply because it matches some string pattern 213 somewhere, or what happens when someone has given their 214 own name to their personal system. 216 Deleting "Received:" fields from message headers is 217 also problematic, as it interferes with message loop 218 detection. In addition, some firewalls delete 219 "Received:" fields in messages passing from the 220 Internet to the local network in addition to messages 221 going the other way, and this actually compromises 222 security as it eliminates trace information vital in 223 determining a hostile message's possible origin. 225 The solution is simple for messages passing from the 226 external Internet to internal hosts: Don't delete 227 Received: headers because this compromises, rather than 228 enhances, security. As for Received: headers going in 229 the other direction, one approach is to obscure host 230 name information using name replacement, hash 231 functions, or encryption, rather than removing the 232 field entirely. Simple encryption schemes lead to host 233 names are meaningless to outsiders but if need be can 234 be analyzed by a security manager to determine the 235 actual underlying name. 237 (2) Firewalls implementing Web proxies often trash URLs 238 which are very long, contain odd (but legal) 239 characters, or contain many separator characters. The 240 result is that Web applications which employ such URLs, 241 such as directory applications, tend not to work 242 properly through many firewall products, even though 243 the URLs being used are completely legal, safe, and 244 correct. 246 (3) Many firewalls which act as SMTP proxy agents implement 247 only the most rudimentary form of SMTP service. The 248 result is that the ability to use many useful SMTP 249 facilities (DSNs, size negotiation, authentication, 250 pipelining, etc.) is eliminated. In the case of DSNs 251 and authentication once again this action lessens 252 security rather than strengthening it. 254 (4) DNS service behind many firewalls works very poorly. 255 Firewalls often implement the concept of a split 256 between the part of a domain the outside world can see 257 and the part the inside world can see. And firewalls 258 are often called upon to create DNS setups of this 259 sort. This is often done poorly -- perhaps it is just 260 too difficult to configure such things properly. The 261 net result often is that such restrictions end up 262 getting summarily dumped, which again may compromise 263 security more than it strengthens it. 265 Note that this also makes it hard to deploy a good 266 mailer on the inside even if the firewall lets the SMTP 267 traffic through to/from the mail hub. A mail hub 268 inside such a setup cannot get a true picture of the 269 outside world, and this once again may end up 270 compromising security rather than strengthening it. 272 (5) Many firewalls handle TCP connections in a way which 273 lies somewhere between acting as a full-fledged 274 application protocol proxy and a transpart connection 275 path. Specifically, they intercept all attempts to open 276 TCP connections across the firewall and respond to them 277 immediately, making the connection initiator think the 278 open has succeeded. They then make a connection of 279 their own to the actual destination host. If that 280 connection succeeds subsequent data is then forwarded 281 from one side to the other, possibly with some 282 additional examination nd/or modification occurring at 283 the firewall, or possibly not. 285 The first problem with this technique arises when the 286 connection from the firewall to the actual destination 287 cannot be opened. There is no way to properly convey 288 the semantics of such a failure to the connection 289 originator since the firewall has already completed the 290 connection to the originator. The firewall must then 291 either content itself with simply closing the 292 connection or else send some protocol-specific 293 response, which applications may interpret quite 294 differently than a transport level connection failure. 295 (In fact such differing interpretation is required in 296 some protocols.) 298 In the case of an SMTP transfer to a destination with 299 multiple MX and A records, for example, existing 300 clients may interpret a successful connection open as 301 constituting a delivery attempt requiring no subsequent 302 connection attempts to other MX or A records. This in 303 turn can lead to delivery failures when one or more 304 hosts in an MX or A record list aren't available for a 305 prolonged period of time. 307 The second problem with this technique arises when 308 modifications are made to packets transferred from one 309 side to the other without full knowledge of the 310 underlying protocol. For example, situations have 311 arisen where firewalls attempt to "censor" an SMTP data 312 stream and end up removing data from that stream, 313 operating under the assumption that since SMTP uses 314 dot-stuffing rather than counted data such editing is 315 acceptable. Unfortunately, the SMTP protocol has 316 changed in recent years and now includes the BDAT 317 command [2] for transferring counted data, among other 318 things. Removing octets from a BDAT data stream 319 inevitably leads to protocol desynchronization, 320 timeouts,transfer failures, and message delivery 321 failures. 323 A similar problem can occur with SMTP's VRFY command, 324 which is a mandatory part of the SMTP protocol. 325 Firewalls like to intercept VRFY because of the 326 perception that VRFY exposes internal information 327 unnecessarily. (This perception is false as comparable 328 exposure occurs with SMTP's RCPT TO, and disabling or 329 interfering with RCPT TO breaks the protocol 330 completely.) Unfortunately, while it is possible to 331 intercept and effectively disable VRFY properly [4], 332 several firewall don't do it correctly. Ways of 333 disabling VRFY incorrectly include returning a 5XX SMTP 334 error unconditionally (which can lead to delivery 335 failures when working with clients that do VRFYs prior 336 to each RCPT TO) and failing to return a properly 337 formatted 2XX SMTP success code (RFC 821 [5] requires 338 that the response to a VRFY include an RFC 822 [6] 339 address enclosed in angle brackets). 341 6. References 343 [1] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. 344 Jones, "SOCKS Protocol Version 5", RFC 1928, April, 1996. 346 [2] Vaudreuil, G., "SMTP Service Extensions for Transmission 347 of Large and Binary MIME Messages", RFC1830, August, 348 1995. 350 [3] Bradner, S., "Key Words for Use in RFCs to Indicate 351 Requirement Levels", RFC 2119, March 1997. 353 [4] Braden, R., "Requirements for Internet Hosts - 354 Application and Support", STD 3, RFC 1123, 355 USC/Information Sciences Institute, October 1989. 357 [5] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 358 821, USC/Information Sciences Institute, August 1982. 360 [6] Crocker, D., "Standard for the Format of ARPA Internet 361 Text Messages", STD 11, RFC 822, UDEL, August 1982. 363 7. Authors' Addresses 365 Ned Freed 366 Innosoft International, Inc. 367 1050 Lakes Drive 368 West Covina, CA 91790 369 USA 370 tel: +1 626 919 3600 fax: +1 626 919 3614 371 email: ned.freed@innosoft.com 373 Kevin Carosso 374 Innosoft International, Inc. 375 1050 Lakes Drive 376 West Covina, CA 91790 377 USA 378 tel: +1 626 919 3600 fax: +1 626 919 3614 379 email: kevin.carosso@innosoft.com 381 8. Full Copyright Statement 383 Copyright (C) The Internet Society (1997). All Rights 384 Reserved. 386 This document and translations of it may be copied and 387 furnished to others, and derivative works that comment on or 388 otherwise explain it or assist in its implementation may be 389 prepared, copied, published and distributed, in whole or in 390 part, without restriction of any kind, provided that the 391 above copyright notice and this paragraph are included on all 392 such copies and derivative works. However, this document 393 itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or 395 other Internet organizations, except as needed for the purpose 396 of developing Internet standards in which case the procedures 397 for copyrights defined in the Internet Standards process must 398 be followed, or as required to translate it into languages 399 other than English. 401 The limited permissions granted above are perpetual and will 402 not be revoked by the Internet Society or its successors or 403 assigns. 405 This document and the information contained herein is provided 406 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 407 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 408 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 409 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 410 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 411 PARTICULAR PURPOSE.