idnits 2.17.1 draft-gupta-ospf-ospfv3-auth-00.txt: -(103): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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 (June 2002) is 7985 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? 'Ref5' on line 41 looks like a reference -- Missing reference section? 'Ref1' on line 71 looks like a reference -- Missing reference section? 'Ref4' on line 72 looks like a reference -- Missing reference section? 'Ref3' on line 72 looks like a reference -- Missing reference section? 'Ref2' on line 74 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 6 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-gupta-ospf-ospfv3-auth-00.txt N. Melam 5 Expires: October 2002 Nokia 6 June 2002 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 [Ref5]. 42 Table of Contents 44 1. Introduction...................................................2 45 2. OSPFv2 to OSPFv3...............................................2 46 3. Authentication.................................................2 47 4. Confidentiality................................................3 48 5. Key Management.................................................3 49 6. SA Granularity.................................................4 51 Authentication/Confidentiality to OSPFv3 June 2002 53 7. Virtual Links..................................................5 54 8. Replay Protection..............................................5 55 Security Considerations...........................................5 56 References........................................................5 57 Acknowledgments...................................................6 58 Authors Addresses................................................6 60 1. Introduction 62 In OSPFv3 for IPv6, authentication fields have been removed from OSPF 63 headers. When running over IPv6, OSPF relies on the IPv6 64 Authentication Header (AH) and IPv6 Encapsulating Security Payload 65 (ESP) to ensure integrity, authentication and/or confidentiality of 66 routing exchanges. 68 This documents describes how IPv6 AH/ESP extension headers can be 69 used to provide authentication/confidentiality to OSPFv3. 71 It is assumed that the reader is familiar with OSPFv3 [Ref1], AH 72 [Ref4], ESP [Ref3], the concept of security associations, tunnel and 73 transport mode of IPsec and the key management options available for 74 AH and ESP (manual keying and IKE) [Ref2]. 76 2. OSPFv2 to OSPFv3 78 Security concerns MUST be taken away from OSPFv3 protocol and IPv6 79 stack MUST provide inherent security to OSPFv3 by using AH/ESP 80 extension headers. It means OSPFv3 protocol MUST not receive any 81 unauthenticated packets. As OSPFv2 has its own security mechanisms, 82 no inherent security needs to be provided by the IPv4 stack. As 83 OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction 84 between the packets can be easily made by IP version. 86 Authentication and confidentiality, if provided, MUST be provided to 87 the entire OSPFv3 header and data. Authentication to the selected 88 portions of IPv6 header, selected portions of extension headers and 89 selected options may also be provided optionally. 91 3. Authentication 93 Transport mode SA is the security association between two hosts or 94 security gateways that are acting as hosts. SA must be tunnel mode if 95 either end of the security association is a security gateway. OSPFv3 96 packets are exchanged between the routers but as the packets are 97 destined to the routers, the routers act like host in this case. So 98 transport mode SA MUST be used in order to provide required security 99 to OSPFv3. 101 Authentication/Confidentiality to OSPFv3 June 2002 103 In order to support OSPFv3 authentication, ESP with NULL encryption� 104 MUST be supported in transport mode. AH� in transport mode SHOULD 105 also be provided. AH in transport mode provides authentication to 106 higher layer protocols, selected portions of IPv6 header, selected 107 portions of extension headers and selected options. ESP with NULL 108 encryption in transport mode will provide authentication to only 109 higher layer protocol data and not to the IPv6 header, extension 110 headers and options. 112 OSPF packets received in clear text and OSPF received with incorrect 113 AH ICV MUST be dropped when authentication is enabled. 115 4. Confidentiality 117 Providing confidentiality to OSPFv3 in addition to authentication is 118 optional. Confidentiality must be implemented using ESP extension 119 header of IPv6 if it is being provided. ESP with non-null encryption 120 in transport mode MUST be used for the providing confidentiality to 121 OSPFv3. 123 5. Key Management 125 OSPFv3 exchanges both multicast and unicast packets. While running 126 OSPFv3 over a broadcast interface, the authentication/confidentiality 127 required is one to many�. Since IKE is based on the Diffie-Hellman 128 key agreement protocol and works only for two communicating parties, 129 it is not possible to use IKE for providing the required one to 130 many� authentication/confidentiality. Manual keying MUST be used for 131 this purpose. In manual keying SAs are statically installed on the 132 routers and these static SAs are used to encrypt/authenticate the 133 data. 135 Since security associations (SAs) are directional, generally 136 different security associations are used for inbound and outbound 137 processing for providing higher security. Following figure explains 138 that it is not possible to use different security associations for 139 inbound and outbound processing in order to provide the required one 140 to many� security. 142 Authentication/Confidentiality to OSPFv3 June 2002 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 same SA for incoming and outgoing direction. 171 A | 172 SAs ------------>| 173 SAs <------------| 174 | 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 same SA 186 and the same SA MUST be used for inbound and outbound processing. 188 6. SA Granularity and Selectors 190 Authentication/Confidentiality to OSPFv3 June 2002 192 Different SA for different interfaces MUST be supported. In the 193 outgoing path, IPv6 source address, OSPF protocol and egress 194 interface ID MUST be used as selectors to locate the SA to be 195 applied. In the incoming path, OSPF protocol, SPI and ingress 196 interface ID MUST used to locate the SA to be applied. Any incoming 197 OSPF protocol packets on the given ingress interface that fail the 198 confidentiality/authentication checks MUST be dropped. 200 7. Virtual Links 202 Different SA than the SA of underlying interface MUST be provided for 203 virtual links. Packets sent out on virtual links use unicast site 204 local addresses as the IPv6 source address and all the other packets 205 use multicast and unicast link local addresses. This difference in 206 the IPv6 source address should be used in order to differentiate the 207 packets sent on interfaces and virtual links. 208 Note: All the details about using IPsec for providing authentication 209 for virtual links are not clear yet. This area can be explored 210 further for more details. 212 8. Replay Protection 214 As it is not possible as per the current standards to provide 215 complete replay protection while using manual keying, replay 216 protection will not be provided for OSPFv3 217 authentication/confidentiality. It is assumed that OSPFv3 protects 218 itself against reply attacks. According to the current standards 219 OSPFv3 has sequence number fields in the packet headers and protects 220 itself against some replay attacks. 222 Security Considerations 224 This memo discusses the use of IPsec AH and ESP headers in order to 225 provide security to OSPFv3 for IPv6. 227 Use of manual keying does not provide very high level of security as 228 compared to IKE but the security provided should be enough for a 229 routing protocol. 231 References 233 1. Coltun, R., Ferguson, D. and Moy, J., OSPF for IPv6�, RFC 2740, 234 December 1999 236 2. Kent, S. and Atkinson, R., Security Architecture for the Internet 237 Protocol�, RFC 2401, November 1998 239 Authentication/Confidentiality to OSPFv3 June 2002 241 3. Kent, S. and Atkinson, R., "IP Encapsulating Security Payload 242 (ESP)�, RFC 2406, November 1998 244 4. Kent, S. and Atkinson, R., "IP Authentication Header (AH)�, RFC 245 2402, November 1998 247 5. Bradner, S., "Key words for use in RFCs to Indicate Requirement 248 Level", BCP 14, RFC 2119, March 1997. 250 Acknowledgments 252 Authors would like to extend sincere thanks to Marc Solsona, Janne 253 Peltonen, John Cruz and Dhaval Shah for providing useful information 254 and critiques in order to write this memo. 256 Authors Addresses 258 Mukesh Gupta 259 Nokia 260 313 Fairchild Drive 261 Mountain View, CA 94043 262 Phone: 650-625-2264 263 Email: Mukesh.Gupta@nokia.com 265 Nagavenkata Suresh Melam 266 Nokia 267 313 Fairchild Drive 268 Mountain View, CA 94043 269 Phone: 650-625-2949 270 Email: Nagavenkata.Melam@nokia.com