idnits 2.17.1 draft-ietf-ipsec-vpn-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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 216 lines == It seems as if not all pages are separated by form feeds - found 3 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 57 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 26 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '... the two routers MUST contain valid IP...' RFC 2119 keyword, line 204: '...the other router MUST contain valid IP...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 123 has weird spacing: '...figured not t...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-1918' is defined on line 259, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1852 (ref. 'RFC-1825') (Obsoleted by RFC 2841) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Naganand Doraswamy (FTP Software) 3 Internet Draft 12 March, 1997 5 Implementation of Virtual Private Network (VPNs) with IP Secrity 6 8 Status of This Memo 10 Distribution of this memo is unlimited. 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a ``working draft'' 21 or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 25 Directories on: 27 ftp.is.co.za (Africa) 28 nic.nordu.net (Europe) 29 ds.internic.net (US East Coast) 30 ftp.isi.edu (US West Coast) 31 munnari.oz.au (Pacific Rim) 33 Abstract 35 This document discusses methods for implementing Virtural Private 36 Networks (VPN) with IP Security (IPSec). We discuss different scenarios in 37 which VPN is implemented and the security implications for each of these 38 scenarios. 40 Contents 42 1. Introduction................................................... 43 2. Scenarios 44 2.1 Road Warrior into Corporate Network 45 2.2 Securing packets only on Internet 46 2.3 Securing packets to Net 10 Hosts 47 2.4 AH in tunnel mode 48 ACKNOWLEDGMENTS.................................................... 49 REFERENCES......................................................... 50 CONTACTS........................................................... 52 1. Introduction 54 The Authentication Header (AH) [RFC-1826] provides integrity and 55 authentication for IP datagrams. ESP provides data confidentiality, 56 integrity, and authentication. These protocols are used to secure packets 57 end to end and are normally called IP Security (IPSec). However, with 58 intervening gateways (firewalls) or because of the 59 faith in their own private networks, some organizations may choose to secure 60 the packets only on the Intenet and let the packets travel in clear text 61 inside the organization. 63 This document discusses some scenarios where IPSec can be used to achieve 64 this functionality. We also discuss the security implications under each of 65 this scenario. 67 Familiarity with the following documents is assumed: "Security 68 Architecture for the Internet Protocol" [RFC-1825], "IP 69 Authentication Header" [RFC-1826], "IP Encapsulated Security Payload" 70 [RFC-1827]. 72 1.1 74 This section defines certain terms used in this memo in order to communicate 75 with greater clarity. 77 NODE Any system implementing the TCP/IP protocol suite. 79 HOST Any IP node that does not forward packets not addressed 80 to the node itself. 82 ROUTER An IP node that forwards packets not addressed to itself. 84 FIREWALL An IP node located on the perimeter of an administrative 85 domain that implements that domain's security policy. 86 A firewall usually performs address and port-based 87 packet filtering and usually has stateful proxy servers 88 for EMAIL and other services. 90 ENCRYPTING FIREWALL A firewall that implements full IP Security, 91 including AH and both tunnel-mode and transport-mode ESP. 93 PROXY SECURITY SERVER A node that encrypts or decrypts traffic on 94 behalf of some other node. Encrypting Firewalls often also 95 function as proxy security servers. 97 KEY MANAGEMENT PROXY A node implementing a key management protocol on 98 behalf of some other node. 100 MOBILE NODE A node that is mobile and is not permanently attached 101 to a fixed location from the perspective of IP. 103 PRIVATE ADDRESS An IP address that is not globally unique and is only 104 useful within a particular private administrative domain. 106 NAT Network Address Translator. A router that selectively 107 translates IP addresses in packets prior to forwarding 108 the packets. NATs are commonly used to connect network 109 regions where private addressing is in use to network 110 regions having conflicting private addressing or having 111 globally-unique addressing. 113 SECURE PACKET In this document this term is used to represent an IP 114 packet with AH and/or ESP. 116 2. Scenarios 118 2.1 Remote Node into Corporate Network 120 Consider the case where a mobile node (host A) needs to communicate with 121 host B behind a firewall (F). In this case, it is necessary 122 that all packets from A to B always go through F. The firewall is 123 configured not to let any unauthenticated packets into the network. There 124 are a few solutions to this problem. 126 2.1.1 Packets tunneled to firewall 127 The host A establishes an SA between itself and F and sends a pkt tunneled 128 to F with the final destination B. In this case, F decrypts/authenticates 129 the pkt and forwards the pkt depending on the rules at F. The pkt is 130 forwarded from F to B either in clear text or using AH/ESP. If the pkt 131 needs to be secured the firewall needs to establish an SA between itself 132 and B. 134 For outbound pkt, i.e. pkts sent from B through the firewall to A, B does 135 not secure the packets to be sent to A. The firewall F after receiving the 136 packet destined to A, secures the packet. B might however secure the packet 137 to F depending on its trust on its internal network. 139 The problem with this is that the end host (B) has to beleive the 140 firewall. It has to assume that the firewall is doing the necessary 141 security on the inbound packets. Also, on the outbound packets it has to 142 assume that they are going to be secured at the firewall. 144 The advantage of this is that the firewall can apply the normal filtering 145 rules on the packet as the inner payload is not encrypted. 147 2.1.2 Packets secured to end host 148 In thiscase, the firewall (F) is authorised to act as 149 a key management proxy for the hosts on either side of it. So when 150 A seeks to initiate a secure session with B, it discovers (either via 151 the KX record of DNS security or via manual configuration) that it 152 should initiate the Key Management exchange with F, with F acting 153 on behalf of B. From A's perspective, this results in a Security 154 Association between A and B, even though the packet will transit F 155 en route to B. In this case, F has the capability of decrypting and 156 examining the packet contents before deciding whether to forward the 157 packet to B or to discard it. This permits IPsec to be used between 158 A and B even though F is still applying its packet filtering policy. 160 The advantage of this approach is that the end host is encrypting and 161 decrypting packets . However, there is still an implicit assumption that 162 the firewall is not changing any traffic. 164 2.1.3 Packets secured to end host and tunneled to firewall 165 In this case, the inner payload is secured to B (transport mode ESP and AH) 166 , and the outer payload tunneled and secured to firewall F. 168 The advantage of this scheme is that the firewall is able to authenticate 169 packets and decide whether to allow the packet or not without applying the 170 normal filtering rules. This is typical of what happens in the networks 171 today, where an employee gets into the corporate network via a dialup PPP. 173 On packets destined from B to A, the packets leaving B has transport mode 174 ESP and AH, and the packet is tunneled from F to A after securing the 175 packet. 177 2.2 Securing packets only on Internet 179 This case handles securing packets between two or more border routers 180 of a topologically distributed organisation (i.e. one organisation 181 having more than one site without direct internal connectivity 182 between all of the organisation's sites). This scenario is 183 applicable when the organization has faith in its private network but not 184 Internet. This model treats Internet as a set of pipes. 186 In this case, Security Associations are setup between the border 187 routers. The border routers enforce a policy where all traffic 188 to or from another site of this organisation must be secured 189 using IPsec before being forwarded and must arrive secured 190 as well. 192 In this case, the KX record for each site probably exists and 193 is configured to point to the border routers for that site. In 194 this way, all nodes outside of that site know that the Border Router 195 handles IPsec on behalf of nodes within that site. 197 In implementing VPN in this mode, one has to be aware of the following: 199 - All packets flowing between the two topologically separated facilites 200 always use the routers that have been configured with security. 202 - All packets between the two routers MUST contain valid IPsec. Any packet 203 received at either router claiming to come from either the other router or 204 from any node protected by the other router MUST contain valid IPsec or be 205 dropped upon receipt. To do otherwise creates a security hole for 206 spoofers. 208 2.3 Securing packets to Net 10 Hosts 210 This handles the case where an organisation is using IP addresses that are 211 private (e.g. use of 10.x.x.x as per RFC-1918). When packets 212 have to be secured to hosts that are in net 10 environment, one needs 213 infrastructure. DNS support is needed to identify where the packets 214 destined for the net 10 hosts can be tunneled to so that, NAT 215 can then forward the packets to this private host. 217 Consider site S with border router R1. Let S1 be some node inside site S 218 and behind R1. Consider some remote node X that is not within the same 219 administrative domain as S or R1. Now consider that X wishes to initiate 220 an IP session with some node S1. X performs a DNS lookup on S1 and 221 receives an authenticated A/AAAA record with S1's address and also obtains 222 a KX record covering S that points to R1. This enables X to know that it 223 should initiate a key exchange session with R1 if X wishes to use IPsec to 224 protect its session to S1. In this case, R1 is behaving as NAT as well as 225 proxy security server. 227 In this scenario, NAT is responsible to impose security on the 228 packets flowing into the net 10 environment and there could be some 229 performance bottlenecks. 231 2.4 AH in tunnel mode 233 AH in tunnel mode is useful in cases such as Scenario 2 of section 2.1 234 where you may have a requiment that says that all packets flowing between 235 two routers need to be authenticated. It is also useful in cases when the 236 end hosts do not implement IPSecurity and decision needs to be made at 237 firewall/router as to which packets should be let into the network. 239 In this scenario, it should be noted that AH does not protect the 240 confidentiality of any data being transmitted and hence this is not 241 strictly speaking a Virtual Private Network. VPNs separate the different 242 logical networks via encryption while AH only provides cryptographic 243 authentication. 245 Note: Some of the discussions above may change depending on the new drafts. 247 Acknowledgments 248 I would like to thank Ran Atkinson and Steve Kent for their valuable 249 input. 251 References 253 [RFC-1825] R. Atkinson, "Security Architecture for the Internet 254 Protocol", RFC-1852, Naval Research Laboratory, July 1995. 255 [RFC-1826] R. Atkinson, "IP Authentication Header", 256 RFC-1826, August 1995. 257 [RFC-1827] R. Atkinson, "IP Encapsulate Security Payload" 258 RFC-1827, August 1995. 259 [RFC-1918] Net 10 (need to add more into) 261 Contact 263 Naganand Doraswamy 264 FTP Software Inc., 265 2 High St., 266 North Andover, MA 01845 267 naganand@ftp.com