idnits 2.17.1 draft-jakma-ospf-integrity-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2328, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- 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 (October 13, 2010) is 4937 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Jakma 3 Working Group DCS, Uni. of Glasgow 4 Internet-Draft M. Bhatia 5 Updates: 2328 (if approved) Alcatel-Lucent 6 Intended status: Standards Track October 13, 2010 7 Expires: April 16, 2011 9 Stronger, Automatic Integrity Checks for OSPF Packets 10 draft-jakma-ospf-integrity-00 12 Abstract 14 This document describes an extension to OSPFv2 and OSPFv3 to allow a 15 stronger integrity check to be applied to the protocol packets, than 16 the default OSPF checksum, which is known to be weak. 18 The extension allows OSPF speakers to negotiate the use of a CRC 19 integrity check, as a new psuedo-authentication type. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 16, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Stronger Checksum mechanism for OSPFv2 . . . . . . . . . . . . 3 58 3.1. Null Authentication Data . . . . . . . . . . . . . . . . . 4 59 4. Stronger Checksum mechanism for OSPFv3 . . . . . . . . . . . . 4 60 4.1. EC-Bit in Options Field . . . . . . . . . . . . . . . . . . 4 61 4.2. Extended Checksum Data Block . . . . . . . . . . . . . . . 5 62 5. Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Stronger Integrity Algorithm Types . . . . . . . . . . . . . . 7 65 7.1. CRC32 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.2. MD5-Digest . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 The integrity of Open Shortest Path First versions 2 83 (OSPFv2)[RFC2328] and 3 (OSPFv3)[RFC5340] packets is protected either 84 through the standard internet protocol checksum, or through some 85 cryptographic integrity scheme within OSPF, or, more rarely, through 86 IPSec. This provides a check against errors that can not be caught 87 by the link-layer integrity checks, e.g. errors in lower layers of 88 the software stack or in hardware of the host. 90 The internet protocol checksum is known to have 91 weaknesses[partridge]. In particular it can not detect re-ordered 92 words and certain patterns of bit flips. If stronger integrity 93 checks are desired, the only option is to use cryptographic HMACs, 94 either with MD5 (all conforming [RFC2328] implementations) or, if 95 supported, the stronger algorithms specified by [RFC5709]. There are 96 some disadvantages though to using the existing support for 97 cryptographic HMACs purely for integrity checking. The algorithms 98 require more computation, which may be noticable on less powerful 99 and/or energy-sensitive platforms. Additionally, the need to 100 configure key material is an additional administrative burden. 102 This documents extends OSPF to allow for the automatic and backward 103 compatible use of stronger integrity checks. Backward compatibility 104 implies the default null authentication type must be used and 105 extended. 107 3. Stronger Checksum mechanism for OSPFv2 109 The null authentication mode of OSPFv2 is extended to make use of the 110 authentication data field of the OSPFv2 packet header. Where 111 previously this field was ignored for null authentication, now an 112 OPTIONAL "Null Authentication Data" structure is recognised there. 114 Implementations MUST provide a means to disable this extension, in 115 case there are non-conforming RFC2328 implementations. 116 Implementations MAY wish to generate a CRC32 checksum by default via 117 this extension, and SHOULD attempt to verify any received, regardless 118 of whether they generate the same or not. 120 3.1. Null Authentication Data 122 0 1 2 3 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Checksum Type | 0xA5 | Data Length | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Ignored | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: Null Authentication Data 132 The authentication data field in the standard OSPFv2 packet header is 133 redefined as shown above, when null authentication is used. The new 134 field definitions are as follows: 136 Checksum Type: 137 This field indicates the new checksum algorithm that the routers 138 must use and is described in detail in the later sections. 139 Magic: 140 This field is set to 0xA5. This magic, in combination with the 141 OSPF and IP packet lengths, signals the use of this extension. 142 Data Length: 143 The length in 4-octet words of the extended checksum data block 144 appended to the OSPFv2 packet. 146 4. Stronger Checksum mechanism for OSPFv3 148 OSPFv3 uses IPSec for protection and does not carry any 149 authentication information in its headers. Thus it is not possible 150 to overload the Null Authentication type as was done in case of 151 OSPFv2. 153 4.1. EC-Bit in Options Field 155 A new EC-bit (EC stands for Extended Checksum) is introduced into the 156 OSPFv3 Options field. Routers MUST set the EC-bit in all OSPFv3 157 packets to indicate that the packet is carrying the new extended 158 checksum data. 160 0 1 2 161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+--+--+--+--+--+ 163 | | | | | | | | | | | | | |EC|L|AF|*|*|DC| R| N|MC| E|V6| 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+--+--+--+--+--+ 165 Figure 2: OSPFv3 Options Field 167 4.2. Extended Checksum Data Block 169 The data block for carrying extended checksum in OSPFv3 is formatted 170 as described below. 172 0 1 2 3 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Checksum Type | 0xA5 | Data Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 ~ Extended Checksum Data Block ~ 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 3: OSPFv3 Options Field 184 The Checksum Type is of two octets and indicates the new checksum 185 algorithm that the routers must use. This is described in detail in 186 the later sections. The next field is a reserved magic field set to 187 0xA5. The Data length field is of two octets and carries the size of 188 the entire extended checksum data block that has been appended to the 189 OSPFv3 payload, specified in units of 4-octet words. The Extended 190 Checksum Data Block carries the checksum data that the recievers will 191 use to verify the integrity of the OSPFv3 protocol payload. 193 5. Generation 195 The same steps are followed as for D.4.1 of [RFC2328]. Additionally, 196 a 2nd integrity check algorithm is also computed over the packet 197 data, with at least the same amount of zero padding, to produce an 198 "extended checksum", which is appended to the OSPFv2 packet. Its is 199 size accounted for in the Null Authentication Data "data length" 200 field and in the IP length, but not in the OSPFv2 packet header, in a 201 similar fashion to the standard OSPFv2 cryptographic authentication 202 mechanism. 204 The "Checksum Type" and "Data Length" fields are set to the 205 appropriate values for the 2nd integrity check algorithm. 207 In case of OSPFv3 the entire extended checksum block is appended to 208 the OSPFv3 packet, with its size accounted for in the IPv6 payload 209 length, but not in the OSPFv3 packet header. 211 Implementations MUST append the extended checksum data, that is 212 carried as part of the OSPF protocol payload, before the link local 213 signaling (LLS) [RFC5613] block (if it exists). 215 +---------------------+ -- -- +---------------------+ 216 | IP Header | ^ ^ | IPv6 Header | 217 | Length = HL+X+Y+Z | | Header Length | | Length = HL+X+Y+Z | 218 | | v v | | 219 +---------------------+ -- -- +---------------------+ 220 | OSPF Header | ^ ^ | OSPFv3 Header | 221 | Length = X | | | | Length = X | 222 | | | | | | 223 | NULL Authentication | | | | | 224 | Length = Y | | | | | 225 |.....................| | X | X |.....................| 226 | | | | | | 227 | OSPFv2 Data | | | | OSPFv3 Data | 228 | | v v | | 229 +---------------------+ -- -- +---------------------+ 230 | | ^ ^ | | 231 | Extended Checksum | | Y | Y | Extended Checksum | 232 | | v v | | 233 +---------------------+ -- -- +---------------------+ 234 | | ^ ^ | | 235 | LLS Data | | Z | Z | LLS Data | 236 | | v v | | 237 +---------------------+ -- -- +---------------------+ 238 ` 240 Figure 4: Extended Checksum Block in OSPFv2 and OSPFv3 242 6. Verification 244 The packet data is padded out, as required by [RFC2328]. 246 In case of OSPFv2, the Null Authentication Data "0xA5" magic field is 247 examined. If it does not match, then verification proceeds as per 248 D.5.1 of [RFC2328]. If it matches, then the IP length in the header 249 MUST be verified. An incoming packet will only contain a valid 250 extended checksum if the length in the IP header = length in OSPF 251 header + "data length" in the NULL Authentication header + data 252 length in the LLS [RFC5613] block (if it exists). Implementations 253 can trivially determine if an LLS block is being carried by 254 inspecting the "L" bit in the OSPF Options field in the HELLOs and 255 DDs. Implementations MUST proceed with regular checksum if these 256 numbers dont match. If they do then the IP checksum field of the 257 OSPF header MUST be ignored. Instead the stronger integrity 258 algorithm specified by the "Checksum Type" field is used, and 259 verified against the corresponding checksum. The packet MUST be 260 discarded if the computed checksum does not match with what's carried 261 in the OSPF packet. 263 In case of OSPFv3, the presence of the EC-bit in the OSPFv3 Options 264 field will indicate that a new checksum algorithm is being used. 265 Routers MUST parse the packet till the end of the OSPFv3 payload till 266 it reaches the start of the extended checksum data block. The 267 processing that follows next is similar to the way its done for 268 OSPFv2 as explained earlier. 270 7. Stronger Integrity Algorithm Types 272 7.1. CRC32 274 The CRC32 algorithm, as used with IEEE 802.3 and defined by [hammond] 275 is used to calculate its 4-byte digest. The length set in the Null 276 Authentication Data thus will be 1. 278 7.2. MD5-Digest 280 The MD5 algorithm, as per 5ref17 of [RFC2328] is used in plain digest 281 mode (i.e. solely over the data, unlike the HMAC mode used by 282 cryptographic authentication) to calculate its 8-byte digest. The 283 length set in the Null Authentication Data thus will be 2. 285 8. IANA Considerations 287 OSPFv2 Null Authentication Checksum Types are maintained by the IANA. 288 Extensions to OSPFv2 that require a new Checksum Type must be 289 reviewed by a designated expert from the routing area. 291 This document assigns OSPF Null Authentication Checksum Types 1 and 292 2, for CRC32 and MD5-Digest respectively. 294 IANA is also requested to allocate EC-bit in the OSPFv3 "Options 295 Registry" 297 9. Security Considerations 299 This extension does not raise any new security concerns. It only is 300 used where operators have chosen not to configure cryptographic 301 security mechanisms. 303 10. References 305 10.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 312 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 313 for IPv6", RFC 5340, July 2008. 315 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 316 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 317 Authentication", RFC 5709, October 2009. 319 [hammond] Hammond, J., Brown, J., and S. Lui, "Development of a 320 Transmission Error Model and an Error Control Model", 321 Technical Report Georgia Institute of Technology, 322 May 1975, . 324 10.2. Informative References 326 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 327 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 329 [partridge] 330 Stone, J., Greenwald, M., Partridge, C., and J. Hughes, 331 "Performance of checksums and CRC's over real data", IEEE/ 332 ACM Trans. Netw. vol 6, num 5, pages 529-543, 1998, 333 . 335 Authors' Addresses 337 Paul Jakma 338 School of Computing Science, University of Glasgow 339 Lilybank Gardens 340 Glasgow G12 8QQ 341 Scotland 343 Email: paulj@dcs.gla.ac.uk 344 Manav Bhatia 345 Alcatel-Lucent 346 Bangalore, 347 India 349 Phone: 350 Email: manav.bhatia@alcatel-lucent.com