idnits 2.17.1 draft-ietf-ospf-ospfv3-auth-01.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-23) 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: ---------------------------------------------------------------------------- == 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: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Security concerns MUST be taken away from OSPFv3 protocol and IPv6 stack MUST provide inherent security to OSPFv3 by using AH/ESP extension headers. It means OSPFv3 protocol MUST not receive any unauthenticated packets. As OSPFv2 has its own security mechanisms, no inherent security needs to be provided by the IPv4 stack. As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction between the packets can be easily made by IP version. -- 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 (April 2003) is 7679 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? '5' on line 41 looks like a reference -- Missing reference section? '1' on line 70 looks like a reference -- Missing reference section? '4' on line 70 looks like a reference -- Missing reference section? '3' on line 71 looks like a reference -- Missing reference section? '2' on line 73 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gupta 3 Internet Draft Nokia 4 Document: draft-ietf-ospf-ospfv3-auth-01.txt N. Melam 5 Expires: October 2003 Nokia 6 April 2003 8 Authentication/Confidentiality for OSPFv3 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes means/mechanisms to provide 33 authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension 34 Header. 36 Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC-2119 [5]. 42 Table of Contents 44 1. Introduction...................................................2 45 2. OSPFv2 to OSPFv3...............................................2 46 3. Authentication.................................................2 47 4. Confidentiality................................................3 48 5. Authentication and Encryption Algorithms.......................3 49 6. Key Management.................................................3 50 7. SA Granularity and Selectors...................................4 51 8. Virtual Links..................................................5 52 9. IPsec rules....................................................5 53 10. Replay Protection.............................................6 54 Security Considerations...........................................6 55 References........................................................7 56 Acknowledgments...................................................7 57 Authors' Addresses................................................7 59 1. Introduction 61 In OSPFv3 for IPv6, authentication fields have been removed from OSPF 62 headers. When running over IPv6, OSPF relies on the IPv6 63 Authentication Header (AH) and IPv6 Encapsulating Security Payload 64 (ESP) to ensure integrity, authentication and/or confidentiality of 65 routing exchanges. 67 This document describes how IPv6 AH/ESP extension headers can be used 68 to provide authentication/confidentiality to OSPFv3. 70 It is assumed that the reader is familiar with OSPFv3 [1], AH [4], 71 ESP [3], the concept of security associations, tunnel and transport 72 mode of IPsec and the key management options available for AH and ESP 73 (manual keying and IKE) [2]. 75 2. OSPFv2 to OSPFv3 77 Security concerns MUST be taken away from OSPFv3 protocol and IPv6 78 stack MUST provide inherent security to OSPFv3 by using AH/ESP 79 extension headers. It means OSPFv3 protocol MUST not receive any 80 unauthenticated packets. As OSPFv2 has its own security mechanisms, 81 no inherent security needs to be provided by the IPv4 stack. As 82 OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction 83 between the packets can be easily made by IP version. 85 Authentication and confidentiality, if provided, MUST be provided to 86 the entire OSPFv3 header and data. Authentication to the selected 87 portions of IPv6 header, selected portions of extension headers and 88 selected options may also be provided optionally. 90 3. Authentication 92 Transport mode SA is the security association between two hosts or 93 security gateways that are acting as hosts. SA must be tunnel mode if 94 either end of the security association is a security gateway. OSPFv3 95 packets are exchanged between the routers but as the packets are 96 destined to the routers, the routers act like host in this case. So 97 transport mode SA MUST be used in order to provide required security 98 to OSPFv3. 100 In order to support OSPFv3 authentication, "ESP with NULL encryption" 101 MUST be supported in transport mode. "AH" in transport mode SHOULD 102 also be provided. AH in transport mode provides authentication to 103 higher layer protocols, selected portions of IPv6 header, selected 104 portions of extension headers and selected options. ESP with NULL 105 encryption in transport mode will provide authentication to only 106 higher layer protocol data and not to the IPv6 header, extension 107 headers and options. 109 OSPF packets received in clear text and OSPF received with incorrect 110 AH ICV MUST be dropped when authentication is enabled. 112 4. Confidentiality 114 Providing confidentiality to OSPFv3 in addition to authentication is 115 optional. Confidentiality must be implemented using ESP extension 116 header of IPv6 if it is being provided. ESP with non-null encryption 117 in transport mode MUST be used for the providing confidentiality to 118 OSPFv3. 120 5. Authentication and Encryption Algorithms 122 The implementations MUST be conformant to the RFCs that describe 123 mandatory-to-implement algorithms for use with ESP and AH. 125 6. Key Management 127 OSPFv3 exchanges both multicast and unicast packets. While running 128 OSPFv3 over a broadcast interface, the authentication/confidentiality 129 required is "one to many". Since IKE is based on the Diffie-Hellman 130 key agreement protocol and works only for two communicating parties, 131 it is not possible to use IKE for providing the required "one to 132 many" authentication/confidentiality. Manual keying MUST be used for 133 this purpose. In manual keying SAs are statically installed on the 134 routers and these static SAs are used to encrypt/authenticate the 135 data. 137 Since security associations (SAs) are directional, generally 138 different security associations are used for inbound and outbound 139 processing for providing higher security. The following figure 140 explains that it is not possible to use different security 141 associations for inbound and outbound processing in order to provide 142 the required "one to many" security. 144 A | 145 SAa ------------>| 146 SAb <------------| 147 | 148 B | 149 SAb ------------>| 150 SAa <------------| 151 | 152 C | 153 SAa/SAb ------------>| 154 SAa/SAb <------------| 155 Broadcast 156 Network 158 If we consider communication between A and B in the above diagram, 159 everything seems to be fine. A uses security association SAa for 160 outgoing packets and B uses the same for incoming packets and vice 161 versa. Now if we include C in the group and C sends a packet out 162 using SAa then only A will be able to understand it or if C sends the 163 packets out using SAb then only B will be able to understand it. 164 Since the packets are multicast packets and they are going to be 165 processed by both A and B, there is no SA for C to use so that A and 166 B both can understand it. 168 The problem can be solved with the following figure where all of them 169 use the same SA for incoming and outgoing direction. 171 A | 172 SAs ------------>| 173 SAs <------------| 174 |3 175 B | 176 SAs ------------>| 177 SAs <------------| 178 | 179 C | 180 SAs ------------>| 181 SAs <------------| 182 Broadcast 183 Network 185 So, all the adjacent routers on a broadcast medium MUST use the same 186 SA and the same SA MUST be used for inbound and outbound processing. 188 7. SA Granularity and Selectors 190 The user SHOULD be given a choice to share the same SA among multiple 191 interfaces or using unique SA per interface. 193 8. Virtual Links 195 Different SA than the SA of underlying interface MUST be provided for 196 virtual links. Packets sent out on virtual links use unicast site 197 local or global IPv6 addresses as the IPv6 source address and all the 198 other packets use multicast and unicast link local addresses. This 199 difference in the IPv6 source address should be used in order to 200 differentiate the packets sent on interfaces and virtual links. 202 As the end point IP addresses of the virtual links are not known at 203 the time of configuration, the secure channel for these packets need 204 to be setup dynamically. The end point IP addresses of virtual links 205 are learnt during the routing table build up process. The packet 206 exchange over the virtual links starts only after the discovery of 207 end point IP addresses. In order to provide security to these 208 exchanges, the routing module should setup a secure IPsec channel 209 dynamically once it acquires the required information. 211 According to the OSPFv3 RFC, the virtual neighbor's IP address is set 212 to the first prefix with the "LA-bit" set from the list of prefixes 213 in intra-area-prefix-LSAs originated by the virtual neighbor. But 214 when it comes to choosing the source address for the packets that are 215 sent over the virtual link, the RFC simply suggests using one of the 216 router's own site-local or global IPv6 addresses. In order to install 217 the required rules for virtual links, the source address also needs 218 to be predictable. So the router MUST use the first prefix with the 219 "LA-bit" set from the list of its own intra-area-prefix-LSAs as the 220 source address of the packet. This makes both the source and 221 destination address of the packets exchanged over the virtual link, 222 predictable on both the routers. 224 9. IPsec rules 226 The following set of rules can be installed in a typical IPsec 227 implementation to provide the authentication/confidentiality to 228 OSPFv3 packets. 230 Outbound Rules for interface running OSPFv3 security: 232 No. interface source destination protocol action 233 1 iface fe80::/10 any OSPF apply 234 2 any src/128 dst/128 OSPF apply 236 Inbound Rules for interface running OSPFv3 security: 238 No. interface source destination protocol action 239 3 iface fe80::/10 any ESP or AH apply 240 4 iface fe80::/10 any OSPF drop 241 5 any src/128 dst/128 ESP or AH apply 242 6 any src/128 dst/128 OSPF drop 244 For outbound rules, action "apply" means encrypting/calculating ICV 245 and adding ESP or AH header. For inbound rules, action "apply" means 246 decrypting/authenticating the packets and stripping ESP or AH header. 248 Rules 4 and 6 are to drop the in-secure OSPFv3 packets without ESP/AH 249 headers. 251 Rules 2, 5 and 6 are meant to secure the packets being exchanged over 252 virtual links. These rules are dynamically installed after learning 253 the end point IP addresses of a virtual link. These rules MUST be 254 installed on at least the interfaces that are connected to the 255 transit area for the virtual link. These rules MAY alternatively be 256 installed on all the interfaces. If these rules are not installed on 257 all the interfaces, clear text or malicious OSPFv3 packets with same 258 source and destination addresses as virtual link end point addresses 259 will be delivered to OSPFv3. Though OSPFv3 drops these packets 260 because they were not received on the right interface, OSPFv3 261 receives some clear text or malicious packets even when the security 262 is on. Installing these rules on all the interfaces insures that 263 OSPFv3 does not receive these clear text or malicious packets when 264 security is turned on. On the other hand installing these rules on 265 all the interfaces increases the processing overhead on the 266 interfaces where there is no IPsec processing otherwise. The decision 267 of installing these rules on all the interfaces or on just the 268 interfaces that are connected to the transit area is a private 269 decision and doesn't affect the interoperability in any way. So this 270 decision is left to the implementers. 272 Rules 1, 3 and 4 are meant to secure the unicast and multicast 273 packets that are not being exchanged over the virtual links. These 274 rules are interface specific. 276 10. Replay Protection 278 As it is not possible as per the current standards to provide 279 complete replay protection while using manual keying, the proposed 280 solution will not provide protection against replay attacks. 282 Fields LS age, LS Sequence Number and LS checksum in LSA header are 283 kept intact in OSPFv3. Though these fields do not provide the 284 complete protection, they certainly help against replay attacks. 286 Security Considerations 288 This memo discusses the use of IPsec AH and ESP headers in order to 289 provide security to OSPFv3 for IPv6. 291 The use of manual keying does not provide very high level of security 292 as compared to IKE but the security provided should be adequate for a 293 routing protocol. 295 References 297 1. Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 2740, 298 December 1999 300 2. Kent, S. and Atkinson, R., "Security Architecture for the Internet 301 Protocol", RFC 2401, November 1998 303 3. Kent, S. and Atkinson, R., "IP Encapsulating Security Payload 304 (ESP)", RFC 2406, November 1998 306 4. Kent, S. and Atkinson, R., "IP Authentication Header (AH)", RFC 307 2402, November 1998 309 5. Bradner, S., "Key words for use in RFCs to Indicate Requirement 310 Level", BCP 14, RFC 2119, March 1997. 312 Acknowledgments 314 Authors would like to extend sincere thanks to Marc Solsona, Janne 315 Peltonen, John Cruz, Dhaval Shah and Abhay Roy for providing useful 316 information and critiques in order to write this memo. 318 We would also like to thank IPsec and OSPF WG people to provide 319 valuable review comments. 321 Authors' Addresses 323 Mukesh Gupta 324 Nokia 325 313 Fairchild Drive 326 Mountain View, CA 94043 327 Phone: 650-625-2264 328 Email: Mukesh.Gupta@nokia.com 330 Nagavenkata Suresh Melam 331 Nokia 332 313 Fairchild Drive 333 Mountain View, CA 94043 334 Phone: 650-625-2949 335 Email: Nagavenkata.Melam@nokia.com