idnits 2.17.1 draft-ietf-ospf-ospfv3-auth-04.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: ---------------------------------------------------------------------------- == 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: ---------------------------------------------------------------------------- -- 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 2003) is 7437 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? 'N5' on line 41 looks like a reference -- Missing reference section? 'N1' on line 235 looks like a reference -- Missing reference section? 'N4' on line 72 looks like a reference -- Missing reference section? 'N3' on line 73 looks like a reference -- Missing reference section? 'N2' on line 75 looks like a reference -- Missing reference section? 'I1' on line 75 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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-04.txt N. Melam 5 Expires: June 2004 Nokia 6 December 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 [N5]. 42 Table of Contents 44 1. Introduction...................................................2 45 2. OSPFv2 to OSPFv3...............................................2 46 3. Authentication.................................................2 47 4. Confidentiality................................................3 48 5. IPsec Requirements.............................................3 49 6. Key Management.................................................4 50 7. SA Granularity and Selectors...................................5 51 8. Virtual Links..................................................5 52 9. Changing Keys..................................................6 53 10. IPsec rules...................................................7 54 11. Replay Protection.............................................8 55 Security Considerations...........................................8 56 Normative References..............................................8 57 Informative References............................................9 58 Acknowledgments...................................................9 59 Authors' Addresses................................................9 61 1. Introduction 63 In Open Shortest Path First - Version 3 (OSPFv3) for IPv6, 64 authentication fields have been removed from OSPF headers. When 65 running over IPv6, OSPF relies on the IPv6 Authentication Header (AH) 66 and IPv6 Encapsulating Security Payload (ESP) to ensure integrity, 67 authentication and/or confidentiality of routing exchanges. 69 This document describes how IPv6 AH/ESP extension headers can be used 70 to provide authentication/confidentiality to OSPFv3. 72 It is assumed that the reader is familiar with OSPFv3 [N1], AH [N4], 73 ESP [N3], the concept of security associations, tunnel and transport 74 mode of IPsec and the key management options available for AH and ESP 75 (manual keying [N2] and Internet Key Exchange (IKE)[I1]). 77 2. OSPFv2 to OSPFv3 79 Security concerns MUST be taken away from OSPFv3 protocol and IPv6 80 stack MUST provide inherent security to OSPFv3 by using AH/ESP 81 extension headers. It means OSPFv3 protocol MUST NOT receive any 82 unauthenticated packets. As OSPFv2 has its own security mechanisms, 83 no inherent security needs to be provided by the IPv4 stack. As 84 OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction 85 between the packets can be easily made by IP version. 87 Authentication and confidentiality, if provided, MUST be provided to 88 the entire OSPFv3 header and data. Authentication to the selected 89 portions of IPv6 header, selected portions of extension headers and 90 selected options MAY also be provided optionally. 92 3. Authentication 94 Transport mode Security Association (SA) is the security association 95 between two hosts or security gateways that are acting as hosts. SA 96 must be tunnel mode if either end of the security association is a 97 security gateway. OSPFv3 packets are exchanged between the routers 98 but as the packets are destined to the routers, the routers act like 99 hosts in this case. So transport mode SA MUST be used in order to 100 provide required security to OSPFv3. 102 In order to support OSPFv3 authentication, "ESP with NULL encryption" 103 MUST be supported in transport mode. "AH" in transport mode SHOULD 104 also be provided. AH in transport mode provides authentication to 105 higher layer protocols, selected portions of IPv6 header, selected 106 portions of extension headers and selected options. ESP with NULL 107 encryption in transport mode will provide authentication to only 108 higher layer protocol data and not to the IPv6 header, extension 109 headers and options. 111 OSPF packets received in clear text or with incorrect AH Integrity 112 Check Value (ICV) MUST be dropped when authentication is enabled. 114 4. Confidentiality 116 Providing confidentiality to OSPFv3 in addition to authentication is 117 optional. Confidentiality must be implemented using ESP extension 118 header of IPv6 if it is being provided. ESP with non-null encryption 119 in transport mode MUST be used for providing the confidentiality to 120 OSPFv3. The user MUST be able to configure the encryption key and 121 the authentication key separately. 123 5. IPsec Requirements 125 In order to implement this specification, the following IPsec 126 capabilities are required. 128 Transport Mode 129 IPsec in transport mode MUST be supported. 131 Traffic Selectors 132 The implementation MUST be able to use interface index, source 133 address, destination address, protocol and direction for choosing 134 the right security action. 136 Manual key support 137 Manually configured keys MUST be able to secure the specified 138 traffic. 140 Encryption and Authentication Algorithms 141 The implementations MUST be conformant to the RFCs that describe 142 mandatory-to-implement algorithms for use with ESP and AH. 144 Dynamic IPsec rule configuration 145 Routing module SHOULD be able to configure, modify and delete 146 IPsec rules on the fly. This is needed mainly for securing 147 virtual links. 149 6. Key Management 151 OSPFv3 exchanges both multicast and unicast packets. While running 152 OSPFv3 over a broadcast interface, the authentication/confidentiality 153 required is "one to many". Since IKE is based on the Diffie-Hellman 154 key agreement protocol and works only for two communicating parties, 155 it is not possible to use IKE for providing the required "one to 156 many" authentication/confidentiality. Manual keying MUST be used for 157 this purpose. In manual keying SAs are statically installed on the 158 routers and these static SAs are used to encrypt/authenticate the 159 data. 161 As security associations (SAs) are directional, generally different 162 security associations are used for inbound and outbound processing 163 for providing higher security. The following figure explains that it 164 is not possible to use different security associations for inbound 165 and outbound processing in order to provide the required "one to 166 many" security. 168 A | 169 SAa ------------>| 170 SAb <------------| 171 | 172 B | 173 SAb ------------>| 174 SAa <------------| 175 | 176 C | 177 SAa/SAb ------------>| 178 SAa/SAb <------------| 179 Broadcast 180 Network 182 If we consider communication between A and B in the above diagram, 183 everything seems to be fine. A uses security association SAa for 184 outgoing packets and B uses the same for incoming packets and vice 185 versa. Now if we include C in the group and C sends a packet out 186 using SAa then only A will be able to understand it or if C sends the 187 packets out using SAb then only B will be able to understand it. 188 Since the packets are multicast packets and they are going to be 189 processed by both A and B, there is no SA for C to use so that A and 190 B both can understand it. 192 The problem can be solved with the following figure where all of them 193 use the same SA for incoming and outgoing direction. 195 A | 196 SAs ------------>| 197 SAs <------------| 198 | 199 B | 200 SAs ------------>| 201 SAs <------------| 202 | 203 C | 204 SAs ------------>| 205 SAs <------------| 206 Broadcast 207 Network 209 So, all the neighbor routers on a network/subnet MUST use the same SA 210 and the same SA MUST be used for inbound and outbound processing. 212 7. SA Granularity and Selectors 214 The user SHOULD be given a choice to share the same SA among multiple 215 interfaces or using unique SA per interface. 217 8. Virtual Links 219 Different SA than the SA of underlying interface MUST be provided for 220 virtual links. Packets sent out on virtual links use unicast site- 221 local or global IPv6 addresses as the IPv6 source address and all the 222 other packets use multicast and unicast link local addresses. This 223 difference in the IPv6 source address is used in order to 224 differentiate the packets sent on interfaces and virtual links. 226 As the end point IP addresses of the virtual links are not known at 227 the time of configuration, the secure channel for these packets needs 228 to be set up dynamically. The end point IP addresses of virtual 229 links are learnt during the routing table build up process. The 230 packet exchange over the virtual links starts only after the 231 discovery of end point IP addresses. In order to provide security to 232 these exchanges, the routing module should setup a secure IPsec 233 channel dynamically once it acquires the required information. 235 According to the OSPFv3 RFC [N1], the virtual neighbor's IP address 236 is set to the first prefix with the "LA-bit" set from the list of 237 prefixes in intra-area-prefix-LSAs originated by the virtual 238 neighbor. But when it comes to choosing the source address for the 239 packets that are sent over the virtual link, the RFC simply suggests 240 using one of the router's own site-local or global IPv6 addresses. 242 In order to install the required security rules for virtual links, 243 the source address also needs to be predictable. So the routers that 244 implement this specification MUST change the way the source and 245 destination addresses are chosen for the packets exchanged over 246 virtual links when the security is enabled on that virtual link. 248 The first IPv6 address with the "LA-bit" set in the list of prefixes 249 advertised in intra-area-prefix-LSAs in the transit area MUST be used 250 as the source address for packets exchanged over the virtual link. 251 When multiple intra-area-prefix-LSAs are originated they are 252 considered as being concatenated and are ordered by ascending Link 253 State ID. 255 The first IPv6 address with the "LA-bit" set in the list of prefixes 256 received in intra-area-prefix-LSAs from the virtual neighbor in the 257 transit area MUST be used as the destination address for packets 258 exchanged over the virtual link. When multiple intra-area-prefix- 259 LSAs are received they are considered as being concatenated and are 260 ordered by ascending Link State ID. 262 This makes both the source and destination addresses of the packets 263 exchanged over the virtual link, predictable on both the routers for 264 security purposes. 266 9. Changing Keys 268 To maintain the security of a link, it may be desirable to change the 269 key values from time to time. The following three-step procedure MAY 270 be provided to rekey the routers on a link without dropping OSPFv3 271 protocol packets or disrupting the adjacency. 273 (1) For every router on the link, create an additional inbound SA for 274 the interface being rekeyed using a new SPI and the new key. 276 (2) For every router on the link, replace the original outbound SA 277 with one using the new SPI and key values. The SA replacement 278 operation should be atomic with respect to sending OSPFv3 packets 279 on the link so that no OSPFv3 packets are sent without 280 authentication/encryption. 282 (3) For every router on the link, remove the original inbound SA. 284 Note that all the routers on the link must complete step 1 before any 285 begin step 2. Likewise, all the routers on the link must complete 286 step 2 before any begin step 3. 288 One way to control the progression from one step to the next is for 289 each router to have a configurable time constant KeyRolloverInterval. 290 After the router begins step 1 on a given link, it waits for this 291 interval and then moves to step 2. Likewise, after moving to step 2, 292 it waits for this interval and then moves to step 3. 294 In order to achieve smooth key transition, all the routers on a link 295 should use the same value for KeyRolloverInterval, and should 296 initiate the key rollover process within this time period. 298 At the end of this procedure, all the routers will have a single 299 inbound and outbound SA for OSPFv3 on the link with the new SPI and 300 key values. 302 10. IPsec rules 304 The following set of rules can be installed in a typical IPsec 305 implementation to provide the authentication/confidentiality to 306 OSPFv3 packets. 308 Outbound Rules for interface running OSPFv3 security: 310 No. interface source destination protocol action 311 1 iface fe80::/10 any OSPF apply 312 2 any src/128 dst/128 OSPF apply 314 Inbound Rules for interface running OSPFv3 security: 316 No. interface source destination protocol action 317 3 iface fe80::/10 any ESP or AH apply 318 4 iface fe80::/10 any OSPF drop 319 5 any src/128 dst/128 ESP or AH apply 320 6 any src/128 dst/128 OSPF drop 322 For outbound rules, action "apply" means encrypting/calculating ICV 323 and adding ESP or AH header. For inbound rules, action "apply" means 324 decrypting/authenticating the packets and stripping ESP or AH header. 326 Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH 327 headers. 329 Rules 2, 5 and 6 are meant to secure the packets being exchanged over 330 virtual links. These rules are dynamically installed after learning 331 the end point IP addresses of a virtual link. These rules MUST be 332 installed on at least the interfaces that are connected to the 333 transit area for the virtual link. These rules MAY alternatively be 334 installed on all the interfaces. If these rules are not installed on 335 all the interfaces, clear text or malicious OSPFv3 packets with same 336 source and destination addresses as virtual link end point addresses 337 will be delivered to OSPFv3. Though OSPFv3 drops these packets 338 because they were not received on the right interface, OSPFv3 339 receives some clear text or malicious packets even when the security 340 is on. Installing these rules on all the interfaces insures that 341 OSPFv3 does not receive these clear text or malicious packets when 342 security is turned on. On the other hand installing these rules on 343 all the interfaces increases the processing overhead on the 344 interfaces where there is no IPsec processing otherwise. The 345 decision of installing these rules on all the interfaces or on just 346 the interfaces that are connected to the transit area is a private 347 decision and doesn't affect the interoperability in any way. So this 348 decision is left to the implementers. 350 Rules 1, 3 and 4 are meant to secure the unicast and multicast 351 packets that are not being exchanged over the virtual links. These 352 rules are interface specific. 354 11. Replay Protection 356 As it is not possible as per the current standards to provide 357 complete replay protection while using manual keying, the proposed 358 solution will not provide protection against replay attacks. 360 Fields LS age, LS Sequence Number and LS checksum in LSA header are 361 kept intact in OSPFv3. Though these fields do not provide the 362 complete protection, they certainly help against replay attacks. 364 Security Considerations 366 This memo discusses the use of IPsec AH and ESP headers in order to 367 provide security to OSPFv3 for IPv6. 369 The use of manual keying does not provide very high level of security 370 as compared to IKE but the security provided should be adequate for a 371 routing protocol. 373 Normative References 375 N1. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, 376 December 1999 378 N2. Kent, S. and R. Atkinson, "Security Architecture for the Internet 379 Protocol", RFC 2401, November 1998. 381 N3. Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 382 (ESP)", RFC 2406, November 1998. 384 N4. Kent, S. and R. Atkinson, "IP Authentication Header (AH)", RFC 385 2402, November 1998. 387 N5. Bradner, S., "Key words for use in RFCs to Indicate Requirement 388 Level", BCP 14, RFC 2119, March 1997. 390 Informative References 392 I1. Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 393 2409, November 1998. 395 Acknowledgments 397 Authors would like to extend sincere thanks to Marc Solsona, Janne 398 Peltonen, John Cruz, Dhaval Shah, Abhay Roy and Paul Wells for 399 providing useful information and critiques in order to write this 400 memo. 402 We would also like to thank IPsec and OSPF WG people to provide 403 valuable review comments. 405 Authors' Addresses 407 Mukesh Gupta 408 Nokia 409 313 Fairchild Drive 410 Mountain View, CA 94043 411 Phone: 650-625-2264 412 Email: Mukesh.Gupta@nokia.com 414 Nagavenkata Suresh Melam 415 Nokia 416 313 Fairchild Drive 417 Mountain View, CA 94043 418 Phone: 650-625-2949 419 Email: Nagavenkata.Melam@nokia.com