idnits 2.17.1 draft-ohara-ipsecparam-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-03-29) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 == It seems as if not all pages are separated by form feeds - found 4 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** 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. ** There are 67 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([Pip97], [Alex97], [Orm96], [Bra97], [Hark97], [RFC-2119], [Drom97], [MSST96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 113: '...he access server MUST be the initiator...' RFC 2119 keyword, line 153: '... in the DHCPINFORM message MUST be the...' RFC 2119 keyword, line 155: '...ver configuration, the end node SHOULD...' RFC 2119 keyword, line 159: '... it SHOULD provide a paramete...' RFC 2119 keyword, line 163: '... address. The DHCPACK MAY include one...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 20, 1997) is 9626 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) -- Missing reference section? 'Hark97' on line 189 looks like a reference -- Missing reference section? 'Drom97' on line 186 looks like a reference -- Missing reference section? 'RFC-2119' on line 95 looks like a reference -- Missing reference section? 'Pip97' on line 200 looks like a reference -- Missing reference section? 'Alex97' on line 178 looks like a reference -- Missing reference section? 'Bra97' on line 181 looks like a reference -- Missing reference section? 'MSST96' on line 192 looks like a reference -- Missing reference section? 'Orm96' on line 196 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. O'Hara 2 Expires May 20th, 1997 New Oak Communications 3 Internet Draft November 20, 1997 5 Configuration of Tunnel Mode Ipsec Endpoint Parameters 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as ``work 19 in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes the assignment of configuration 30 parameters to IPsec tunnel mode client endpoints. Single user 31 computers that are connecting into corporations via Internet 32 Service Providers, ISP's, using Tunnel mode IPsec may need to 33 have configuration information supplied to them, such as inner 34 ip address, DNS server addresses, WINS server addresses, etc. 36 This document describes a method utilized by New Oak 37 Communications to pass these parameters between it's Extranet 38 Access Switch and it's IPsec client software. 40 TABLE OF CONTENTS 42 STATUS OF THIS MEMO...........................................1 44 ABSTRACT......................................................1 46 1. INTRODUCTION...............................................2 48 2. IP ADDRESS ASSIGNMENT METHOD...............................2 50 3. DNS AND WINS ADDRESS ASSIGNMENT............................3 51 4. SECURITY CONSIDERATIONS....................................4 53 5. REFERENCES.................................................4 55 6. AUTHOR'S ADDRESS...........................................5 57 1. Introduction 59 Traditional use of Tunnel Mode IPsec has been focused at 60 firewall to firewall connections with state configured at 61 each end. This is well suited for branch office routing, but 62 is less appropriate for internet remote access, where a 63 single user system, such as a home computer or laptop is 64 connected to an Internet Service Provider's Point of Presence, 65 POP. In this model the end system will have it's IP configuration 66 initially configured through IPCP in the dial up case or via 67 DHCP in the case of a cable modem or ADSL. It is desirable 68 for the IPsec tunnel parameters and policy to be downloaded to 69 the end user's system in similar, but secure manner. 71 Tunnel mode IPsec is well suited to allow traveling or home users 72 the opportunity to tunnel directly from their systems into 73 corporate sites. In doing so the user would first connect to a 74 ISP's POP. Then the user would initiate a connection with a 75 access server on the edge of their network that would serve 76 as the other end of the IPsec tunnel. 78 Establishment of a secure tunnel hides the corporation's network 79 topology and allows the end users system to operate just as if it 80 were an internal system. The end users system will need to 81 be assigned a new end node address for use inside the IPsec tunnel 82 and other addresses such as those of DNS and WINS servers. In this 83 draft the terms "end node" read as a home or traveling user's PC, 84 and "access server" as the device that exists between the corporate 85 Intranet and the Internet terminates IPsec tunnel connections. 87 This document assumes that the reader is familiar with the related 88 documents "The resolution of ISAKMP with Oakley" [Hark97], and 89 "Dynamic Host Configuration Protocol, RFC 2131" [Drom97], that 90 provide important background for this specification. 92 In this document, the key words "MAY", "MUST", "recommended", 93 "required", and "SHOULD", are to be interpreted as described in 94 [RFC-2119]. 96 2. IP ADDRESS ASSIGNMENT 98 Assignment of a Inner IP address is accomplished by using the access 99 server supplied Proxy ID responder, IDur, supplied by the initiator 100 (server) as part of the Quick Mode exchange undertaken in 101 ISAKMP phase 2. To utilize the proxy ID's in this way requires that 102 the phase 2 initiator is the server and that the responder (the end 103 node) accepts that address as it's inner, or tunneled address. 105 ISAKMP usage [Hark97] and [Pip97] describe the 2 stage process 106 for establishment of a Security Association, SA. Phase 1 establishes 107 a secure connection for SA negotiation. During Phase 2 this 108 negotiation is accomplished within the authenticated and protected 109 channel constructed in phase 1. Phase 2 is characterized by 1 or more 110 Quick mode exchanges. 112 When the end node initiates the IPsec tunnel it will be the Phase 1 113 initiator. During Phase 2 the access server MUST be the initiator, as 114 shown below. 116 Quick Mode is defined as follows from [Hark97]: 118 Initiator (server) Responder (end node) 119 -------------------- ---------------------- 120 HDR*, HASH(1), SA, Ni 121 [, KE ] [, IDui, IDur ] --> 122 <-- HDR*, HASH(2), SA, Nr 123 [, KE ] [, IDui, IDur ] 124 HDR*, HASH(3) --> 126 Where the contents of IDui are specified as follows: 128 Identification Type for IDui and IDur will be: ID_IPV4_ADDR 1 130 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 132 Summary: 134 By reversing the Phase 1 and Phase 2 initiator roles and using the 135 supplied IDur as the tunneled source address the problem of how to 136 supply a remote user a tunneled, inner address can be resolved. This 137 reversal of roles is within the scope of the draft [Hark97] and 138 provides secure assigment method protected by the ISAKMP SA. 140 3. DNS and WINS ADDRESS ASSIGNMENT 142 When the end node has received its tunnelled address and the IPsec 143 tunnel has been established, the end node may require the addresses 144 for DNS and WINS servers inside the corporate network. To obtain 145 these addresses, the end node uses the Dynamic Host Configuration 146 Protocol (DHCP) [Drom97] as follows: 148 The end node sends a tunnelled unicast DHCPINFORM message under the 149 protection of the just-established IPsec SA. The source address 150 inside the tunnel is the IPv4 address received from the server 151 in IDur (as described in section 2), while the destination address 152 is the server's IPv4 address on the corporate network, as provided 153 in IDui. The "ciaddr" field in the DHCPINFORM message MUST be the 154 same as the end node's source address inside the tunnel. If the 155 end node requires DNS server configuration, the end node SHOULD 156 provide DHCP option 55 (Parameter Request List) as specified in 157 RFC 2132, and include DHCP option 6 (Domain Name Server option) 158 in the list. If the end node requires WINS server configuration, 159 it SHOULD provide a parameter request list that includes DHCP option 160 44 (NetBIOS over TCP/IP Server option). 162 The server responds by sending a tunnelled unicast DHCPACK message 163 to the end node's tunnelled address. The DHCPACK MAY include one 164 or more DNS servers, provided by DHCP option 6, and MAY include one 165 or more WINS servers, provided by DHCP option 44. 167 4. Security Considerations 169 Protection of corporate network topology is of concern and it 170 should be observed that tunnel addresses assigned with this 171 method are transmitted under the protection of the ISAKMP SA, 172 while the DNS and WINS server addresses are protected by the IPsec 173 SAs. Thus, the information is no more (and no less) secure than 174 the SAs themselves. 176 5. References 178 [Alex97] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 179 Extensions", RFC 2132, March 1997 181 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 182 Requirement Levels", RFC2119, March 1997. 184 Expires May 20th, 1997 186 [Drom97] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 187 Bucknell University, March 1997. 189 [Hark97] Harkins, D., Carrel, D., "The resolution of ISAKMP with 190 Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt. 192 [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 193 "Internet Security Association and Key Management Protocol (ISAKMP)", 194 version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}. 196 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 197 1, TR97-92, Department of Computer Science Technical Report, 198 University of Arizona. 200 [Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation 201 for ISAKMP", version 5, draft-ietf-ipsec-ipsec-doi-05.txt. 203 6. Author's Address 205 John O'Hara 206 New Oak Communications, Inc. 207 125 Nagog Park 208 Acton, Massachusetts, 01720 210 johara@newoak.com 212 (978) 266 1011 voice