idnits 2.17.1 draft-ietf-ipsec-icmp-options-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 -- 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 102 has weird spacing: '... unlike tradi...' -- 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 (September 1998) is 9348 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: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Michael Richardson mcr@sandelman.ottawa.on.ca 2 INTERNET-DRAFT Sandelman Software Works 3 v1.0, September 1998 4 Expires in six months 6 Options for handling ICMP messages that must be forwarded 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 areas, 12 and its working groups. Note that other groups may also distribute 13 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 documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), 24 or ftp.isi.edu (US West Coast). 26 Abstract 28 This document discusses three options for securely communicating ICMP 29 messages from one IPsec security gateway to another. This document 30 expands upon section 6 of the IPsec architecture draft. 32 Table of Contents 34 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 35 1.1. Definition of terminology . . . . . . . . . . . . . . . . . 2 36 1.2. The end-to-end and transport cases . . . . . . . . . . . . . 3 37 2. Introduction to the problem . . . . . . . . . . . . . . . . . . 3 38 3. Why is this not a simple problem . . . . . . . . . . . . . . . . 3 39 4. Discard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 40 5. ICMP SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 41 6. Implicit ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 4 42 7. ISAKMP ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 43 8. Security Considerations: . . . . . . . . . . . . . . . . . . . . 5 44 9. References: . . . . . . . . . . . . . . . . . . . . . . . . . . 5 45 9.1. Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 46 9.2. Expiration and File Name . . . . . . . . . . . . . . . . . . 6 48 1. Introduction 50 1.1. Definition of terminology 52 Here is a network of two security gateways, a client node and a server 53 node. 55 E1---{G1}--{R1}--{G2}--{R2}--E2 57 E1 and E2 are end nodes using TCP or UDP. 58 G1/G1 are security gateways. 59 Rx are routers. 61 There are both application endpoints and security association endpoints, 62 they will be distinguished with the following terms: 64 E1 is the transport layer originator. TLO 66 E2 is the transport layer target. TLT 68 E1/G1 69 is a network layer originator/target pair. NLO/NLT/ 71 G1/G2 72 is a network layer originator/target pair. 74 G2/E2 75 is a network layer originator/target pair. 77 In addition, it is necessary to distinguish three interfaces of the 78 security gateways at which a forwarding decision may need to be made: 80 red interface 81 is the interface that is exposed to the Internet 82 black interface 83 is the interface that is connected only to the internal network 85 tunnel interface 86 is the logical interface that results from a packet traversing an 87 encrypted/authenticated tunnel and then decrypted. In general 88 AH/ESP packets arrive on the red interface, are 89 authenticated/decrypted (i.e. decapulated). The inner packet, once 90 decapsulated can logically be thought to have arrived on a third 91 interface for the purposes of forwarding policy. 93 1.2. The end-to-end and transport cases 95 In the case where security gateways are not involved (i.e. the end-to- 96 end case), then the two end nodes (E1,E2) and the black interface can 97 simply be considered to be the on-board protocol stack. 99 2. Introduction to the problem 101 The Internet Control Message Protocol (ICMP) is a protocol carried by IP 102 networks that is unlike traditional protocols like TCP, UDP. ICMP deals 103 with meta information about the network. As such, ICMP messages are 104 really an integral part of a TCP/UDP flow and should get a similar 105 treatment by security gateways as the TCP/UDP flows themselves. 107 Consider a per-host ARCHSEC, section 4.4.2 or per-host keyed SA between 108 G1 and G2 on behalf of hosts E1 and E2. For reasons outlined in SMB96, 109 it is should be considered typical for gateways to implement per-host or 110 per-port keying. 112 Gateway G2 can receive ICMP messages from four places: G1, R1, R2 and 113 E2. Some of these hosts should legitimately be able to send ICMP 114 messages to host E1 or host E2. ICMPIPSECV4 and ICMPIPSECV6 makes a 115 determination of which of these hosts may be able to send which kinds of 116 ICMP messages. 118 This document describes three possible mechanisms by which gateways G1 119 and G2 may arrange for these reasonable ICMP message to be related to 120 either hosts E1 or E2. 122 3. Why is this not a simple problem 124 The IPsec SPD defined in ARCHSEC and negotiated by IKE Pip98, provides 125 for a set of selectors to determine the policy for determining admission 126 into an IPsec SA. An ICMP message from E2 to E1, from R2 to E1 and from 127 G2 to E1 will not satisfy the admission policy of G2. 129 Trivially G2 could be modified to permit ICMP messages to be transmitted 130 if they arrive on its black interface, or are generated internally. 131 However, upon exit from the tunnel at G1, G1 would consider these ICMP 132 messages to be violations of the SPD and would refuse to forward them. 133 It is for this reason that a more sophisticated solution must be 134 described, standardized and possibly negotiated with IKE. 136 Four methods of handling ICMP messages are described herein: 138 discard 139 the ICMP message is dropped 141 explicit ICMP SA 142 where a seperate SA is established for ICMP messages. 144 implicit ICMP SA 145 where the selector mechanism is modified to accept ICMP messages. 147 ISAKMP 148 where the pre-existing ISAKMP SA is used to relay information that 149 would normally be carried by ICMP. 151 4. Discard 153 The ICMP packet is dropped. The section on that type may give 154 suggestions about other actions that may be desireable for heuristic 155 reasons (i.e. do an PMTU probe), however, a compliant system may 156 completely ignore this ICMP packet. 158 5. ICMP SA 160 Upon receiving an ICMP message from R2 or E2, G2 forward it using t an 161 SA configured to accept ICMP messages of this type/code. If no such SA 162 exists, it should, policy permitting, be created and negotiated with 163 IKE. 165 The proposal parameters for this SA, if not explicitely configured, 166 should be at least as strong as any other SA that is currently being 167 used between the set of end-points. In particular, if encryption (ESP) 168 is being used for any data might be exchanged by the two security 169 gateways, then the same or better encryption should be used for this SA. 170 This restriction is because some ICMP messages echo parts of an 171 offending packet as part of their error processing. Should a weaker 172 encryption algorithm (or no encryption) be used, then data may get 173 revealed. 175 The SPD for this SA should be configured to accept the union of all 176 sources and destinations for which communication is currently 177 configured. 178 The creation and subsequent use of this SA may reveal patterns of 179 traffic which one would not always want to reveal. 181 6. Implicit ICMP 183 Upon receiving an ICMP message from R2 or E2, G2 forward it using the 184 SA-pair that was used to send the offending packet. The difficulty is 185 in finding the right SA to associate with the ICMP message. 187 In many cases it is possible to use the copied packet that ICMP messages 188 will returns as a payload. The data contained as payload of the ICMP 189 message is to be treated as a packet. The tunnel exit SPD is to be 190 applied to this packet. This will result in the incoming SA on which the 191 packet arrived. The corresponding outgoing SA should then be used to 192 send the packet. 194 At G1, (the other end of the tunnel), the ICMP message will be received. 195 It will fail the exit criteria of the tunnel. Noting that it is an ICMP 196 message of a type that should be put through the tunnel, G1 should be 197 able to again use the contained packet to lookup at SA. It can then 198 verify that the ICMP packet was received using the corresponding 199 incoming SA. 201 As an alternative, G2 could take the offending packet from the ICMP 202 message and swap the src/dst and src-port/dst-port and attempt to locate 203 an SA based upon this information. 205 7. ISAKMP ICMP 207 Upon receiving an ICMP message from R2 or E2, G2 does not forward it. 208 Instead, it forwards this packet via the key management interface to the 209 key management system. The key management daemon will send an ISAKMP 210 Notify message to the other end. The definition of appropriate Notify 211 messages is left to the individual ICMP messages. 213 8. Security Considerations: 215 This entire document discusses a security protocol. 217 9. References: 219 RFC-1825 220 R. Atkinson, "Security Architecture for the Internet Protocol", 221 RFC-1825, August 1995. 223 ICMPIPSEC 224 M. Richardson, "Options for handling ICMP messages that must be 225 forwarded" work in progress: draft-ietf-ipsec-icmp-options-00.txt, 226 September 1998 228 ICMPIPSECV4 229 M. Richardson, "IPv4 ICMP messages and IPsec security gateways" 230 work in progress: draft-ietf-ipsec-icmp-handle-v4.txt, September 231 1998 233 ICMPIPSECV6 234 M. Richardson, "IPv6 ICMP messages and IPsec security gateways" 235 work in progress: draft-ietf-ipsec-icmp-handle-v6-00.txt, 236 September 1998 238 ARCHSEC 239 R. Atkinson, S. Kent, "Security Architecture for the Internet 240 Protocol", work in progress: draft-ietf-ipsec-arch-sec-07.txt, 241 July 1998 243 RFC-1191 244 J. Mogul, S. Deering, "Path MTU Discovery", RFC-1191, November 245 1990. 247 KSM-AH 248 New AH draft. 250 Gupta97-1 251 V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Goals and 252 Requirements", draft-ietf-mobileip-ft-req-00.txt, work in 253 progress: Jan. 20, 1997 255 Gupta97-2 256 V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Guidelines 257 for Firewalls and Mobile IP entities", draft-ietf-mobileip- 258 firewall-trav-00.txt, work in progress: March 17, 1997 260 RFC-1256 261 S. Deering, "ICMP Router Discovery Messages." Sep-01-1991. 263 RFC-1885 264 A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) 265 for the Internet Protocol Version 6 (IPv6)." December 1995. 267 RFC-0791 268 J. Postel, "Internet Protocol." Sep-01-1981. 270 RFC-0792 271 J. Postel, "Internet Control Message Protocol.", Sep-01-1981. 273 RFC-0950 274 J.C. Mogul, J. Postel, "Internet Standard Subnetting Procedure." 275 Aug-01-1985. 276 Pip98 277 Piper, D., "The Internet IP Security Domain Of Interpretation for 278 ISAKMP", version 8, draft-ietf-ipsec-ipsec-doi-08.txt. 280 IKE 281 Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft- 282 ietf-ipsec-isakmp-oakley-06.txt. 284 9.1. Author's Address 286 Michael C. Richardson 287 Solidum Systems Corporation 288 940 Belfast Road 289 Ottawa, ON K1G 4A2 290 Canada 292 Telephone: +1 613 244-4804 293 EMail: mcr@sandelman.ottawa.on.ca 295 9.2. Expiration and File Name 297 This draft expires February 1999 299 Its file name is draft-ipsec-icmp-options-00.txt