idnits 2.17.1 draft-wang-ion-sec-scsp-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-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: ---------------------------------------------------------------------------- ** 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. ** 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. == There is 1 instance 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 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages -- Found 12 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 424: '...agement protocol MAY be used to negoti...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '1' on line 446 looks like a reference -- Missing reference section? '2' on line 449 looks like a reference -- Missing reference section? '3' on line 452 looks like a reference -- Missing reference section? '4' on line 455 looks like a reference -- Missing reference section? '6' on line 461 looks like a reference -- Missing reference section? '7' on line 468 looks like a reference -- Missing reference section? '8' on line 473 looks like a reference -- Missing reference section? '9' on line 476 looks like a reference -- Missing reference section? '14' on line 491 looks like a reference -- Missing reference section? '11' on line 483 looks like a reference -- Missing reference section? '12' on line 486 looks like a reference -- Missing reference section? '10' on line 479 looks like a reference -- Missing reference section? '5' on line 458 looks like a reference -- Missing reference section? '13' on line 489 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT: Cliff X. Wang 2 IBM Corp. 4 S. Felix Wu 5 NCSU 7 Security Analysis to Server Cache Synchronization Protocol 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any Internet 25 Draft. Distribution of this document is unlimited. 27 Abstract 29 Server Cache Synchronization Protocol SCSP [1], [2], [3], [4] is used 30 to solve the generalized cache synchronization/cache -replication 31 problem for distributed protocol entities. In a client-server 32 paradigm, SCSP synchronizes caches (or a portion of the caches) of a 33 set of server entities of a particular protocol which are bound to a 34 Server Group. 36 This document provided a security analysis of the current SCSP 37 framework and identified potential threats to the protocol operation. 38 Possible solutions to secure the SCSP from potential attacks are 39 presented and discussed. 41 It is intended in this document to provide analysis and solution to 42 the protocol independent part of SCSP. Security considerations with 43 respect to SCSP application of a specific protocol is beyond the 44 scope of this draft. 46 1. Introduction 48 SCSP contains three sub protocols: the "Hello" protocol, the "Cache 49 Alignment" Protocol and the "Cache State Update" protocol. The Hello 50 protocol is used to monitor the status of the connections between the 51 Local Server (LS) and its Directly Connected Servers (DCS) (i.e., 52 neighbors). The "Cache Alignment" protocol is used to synchronize the 53 cache of an initializing LS with the cache of its DCSs. The "Cache 54 State Update" protocol is used to update the state of cache entries 55 once the servers are synchronized. 57 Synchronization is performed on a per Server Group/Protocol basis. 58 That is, a separate instance of the protocol is run for each Server 59 Group. Therefore, the SGID/PID pair uniquely identifies an instance 60 of SCSP. A server group contains one LS and one or multiple DCS 61 associated with this LS. Note that in this draft, LS and DCS are 62 sometimes referred as SCSP entities. A separate instance of the 63 "Hello" and "Cache Alignment" protocol are maintained for each DCS of 64 the Server Group (except for the scenario of aggregating Protocol 65 ID/SGID pairs). State machines exist to execute the protocol 66 independently for each DCS session. For more information, refer to 67 [1]. 69 For a given server group, SCSP entities, including LS and DCSs, are 70 distributed on different end hosts or routers. 72 Three types of SCSP messages [1] are used in the SCSP protocol. 73 "Hello" messages are used to check whether a DCS is operational and 74 whether the connections between the LS and the DCS are bi- 75 directional, unidirectional, or non-functional. "Hello" message is 76 periodically sent from LS to its DCSs. "Cache Alignment" (CA) 77 messages are used by an LS to synchronize its cache with that of the 78 cache of each of its DCS. A CA message contains a CA header followed 79 by zero or more Cache State Advertisement Summary records (CSAS 80 records). "Cache State Update" (CSU) messages are used to dynamically 81 update the state of cache entries in servers on a given PID/SGID 82 basis. CSU messages contain zero or more "Cache State Advertisement" 83 (CSA) record each of which contains the state of a particular cache 84 entry. 86 These SCSP messages are exchanged between LS and its associated DCSs. 88 This implies the possibility of potential attacks directly on the 89 SCSP protocol operations. It is the purpose of this draft to 90 identify these potential security threats and provide solutions to 91 secure the operations of SCSP. The scope of this draft is limited to 92 the protocol independent part of SCSP. However, additional protocol 93 dependent security analysis may also need to be carried out when SCSP 94 is applied to a specific client-server protocol. The analysis and 95 solution to the security threats related to SCSP's application to a 96 specific protocol is beyond the scope of this document. 98 2. Security Analysis of SCSP 100 SCSP is used to provide cache synchronization/cache-replication for 101 distributed servers. Since servers are usually the crucial part of 102 some protocol operations, they are usually the targets for attack. 103 It is important to secure servers from potential attacks. This 104 section attempts to identify the potential security threats 105 associated with running SCSP to synchronize the distributed servers. 106 It is presented in such a way that the analysis is independent of the 107 protocols associated with the server synchronization. Security 108 analysis with respect to specific protocols may be studied further. 110 Security threats for SCSP can be classified into two types: insider 111 attack and outsider attack. An insider attack refer to the event that 112 the attacker has means to break into one or more SCSP entities 113 (either an LS or a DCS) and to compromise these SCSP entities. On the 114 other hand, an outsider attacker can only eavesdrop or intercept SCSP 115 protocol messages on a link. In the following sections, discussions 116 are presented on what types of attacks are possible on the SCSP 117 operation, either as an insider attacker or as an outside attacker. 118 Enhancement to the SCSP protocol to deal with these attacks is also 119 suggested in Section 3. 121 2.1 Outsider Threats for SCSP 123 An outsider attacker has access only to the links between SCSP 124 entities. The security threats concentrate mostly on SCSP messages 125 exchanged between SCSP entities. 127 Type 1 - Unauthorized access threat 129 Access control refers to the process of identifying legitimate access 130 request and enable information exchange between local and authorized 131 remote entities. For each SCSP entity, two types of message exchange 132 are involved: the first type is the protocol specific message 133 exchanges between the SCSP entity (server) and its clients. The 134 second type is the SCSP message exchange between SCSP entities 135 (distributed servers). The protocol message exchange between client 136 and server is usually defined in the specific protocol involved and 137 is actually outside the scope of SCSP. Security analysis for those 138 message are not addressed here. This document only discuss access 139 control related to SCSP message exchange. 141 Unauthorized access threat refers to the action that un-authorized 142 entity can send fake or illegitimate messages to SCSP entities in 143 order to disturb the normal operation or to inject false information 144 to overwrite the server database. For example, an attacker can send a 145 spoofed CSU request to participating servers in a server group to 146 update their server cache. This spoofed CSU request can overwrite 147 current valid server entry with an invalid entry. This can achieve 148 the effect that the protocol being synchronized may start function 149 incorrectly. For example, when SCSP is used to synchronize Classic IP 150 server, a modified ATMARP cache entry may lead to failure of new SVC 151 setup to a particular IP host. In the case that the affected IP host 152 is a gateway, further IP routing function will be affected. 154 Another types of illegal access is that an illegitimate entity sends 155 a request to a server for information it is not authorized to 156 acquire. Without server access control, an attacker can retrieve 157 information from server and uses the acquired information to plan for 158 additional attacks. Generally the server database should has 159 restrictive access privilege and only authenticated messages are 160 allowed to be passed for processing. 162 SCSP message authentication can eliminate such attacks from un- 163 authorized outside attackers. Spoofed messages originating from 164 untrusted or unauthorized entities will fail authentication check, 165 thus eliminate unauthorized access to SCSP servers. Furthermore, it 166 is also suggested that unsuccessful access attempts should be logged 167 for further detection of intrusions. 169 In the current SCSP framework, SCSP messages between servers have an 170 authentication extension, which will be discussed in detail in 171 Section 3.1. 173 Type 2 - Modification of information threat 175 Modification of information attack refers to the act that legitimate 176 messages are altered by the attacker when message authentication is 177 absent. The intruder may alter in-transit legitimate SCSP messages 178 generated by an authorized entity in such way that normal operation 179 of servers synchronization is jeopardized. The "Hello", "Cache 180 Alignment", and "Cache State Update" messages have 3 parts in every 181 packet: the fixed part, the mandatory part, and the extension part. 182 Modification of any field in any part is prohibited for the normal 183 operation of SCSP operation. Any message modification may affect the 184 state of the HFSM or that of CAFSM, or the server cache entry, 185 resulting in various consequences of different severity levels, from 186 server group synchronization performance degradation, cache entry 187 mis-alignment, to total server group shutdown due to HFSM shutdown 188 caused by error messages. 190 One example would be that the attacker can modify the Protocol ID or 191 the Server Group ID field and these modifies messages will be flushed 192 by the receiving server. If messages are being flushed continuously 193 at the receiving server, the CAFSM or the HFSM may time out, leading 194 to the loss of server synchronization. Of course, modification of any 195 other field will cause similar problems for normal operation. 197 Modification of information threat is very similar to access control 198 threat such that SCSP servers process fake or modified illegitimate 199 messages. Thus applying SCSP message authentication will be able to 200 keep the integrity of SCSP messages and protect SCSP servers from 201 such information modification threat. Un-authenticated or 202 authentication failed messages will be flushed by the server and only 203 those authenticated messages are processed. 205 Type 3 - Message sequencing threat 207 The message sequencing threat is the danger that messages may be 208 arbitrarily re-sequenced, delayed or replayed back such that normal 209 operations of the SCSP entities are japordized. SCSP uses sequence 210 number in its information exchange. Message sequencing threat is both 211 realistic and significant. For example, during the "Cache summarize" 212 process, a play back attack can destroy the correct operation of the 213 Cache Alignment State Machine and set the finite state machine to an 214 incorrect "Master/Slave" state. Specifically, when the LS is slave 215 during the "Cache summarize" process and received a played back CA 216 message from the attacker which has an earlier CA sequence number, 217 the Local Server will be fooled to think that an error has occurred 218 and switch its state to "Master/Slave" state erroneously, 219 interrupting its normal server function for its clients. 221 This type of threat can be avoided by combining both authentication 222 and some kind of timestamp or challenge-response �5�. Message 223 authentication guarantees that the messages have not been altered and 224 timestamp or challenge-response can be used to detect playbacked 225 messages. 227 Type 4 - Disclosure of information threat 229 The disclosure threat is the danger that SCSP message is obtained and 230 disclosed to the unintended party. When the SCSP server lacks access 231 control, any un-authorized party can contact and retrieve information 232 from the unrestricted SCSP entities. Or the attacker can eavesdrop on 233 the links to steal the information exchanged among SCSP entities. The 234 attacker can use the stolen information to plan further attack, eg., 235 attacks on other servers in the server group. 237 To handle this concern, server access control and SCSP messages 238 encryption are needed. After encryption, the whole cipher message 239 usually needs to be authenticated. Otherwise, without authentication, 240 cut-and-paste attack is possible. 242 Type 5 - Denial of service threat 244 Denial of service threat usually refers to the type of attack that 245 stops or slows the normal operation of SCSP entities by diverting or 246 depleting resources, or by exploiting certain implementation 247 shortfall (weakness). 249 One particular scenario of denial of service threat is that without 250 access control, an attacker can simply flood the SCSP server with 251 illegitimate SCSP messages. Queuing and processing of these illegal 252 messages may saturate the resources (message buffer, CPU cycle, etc) 253 of SCSP entities, and legitimate users may be deprived of gaining 254 normal server operation because of resource exhaustion. 256 Other types of possible attacks at different level are possible. For 257 example, the intruder can repeatedly placing/disconnecting SVCs to 258 the SCSP entities if the ATM is the media used. This may result SCSP 259 entities lose part or all of its normal operation capacity. However, 260 since the current context concentrates on security threats on SCSP 261 protocol operation and SCSP entities only, discussion on the ATM 262 level security is outside the scope of this draft. 264 Denial of service attacks are hard to prevent. Access control and 265 message authentication may drop illegal flooding messages at an early 266 processing time, but can not fully protect server from attack until 267 the message flooding origination is detected and stopped. The best 268 protection will reply on a sophisticated network infrastructure 269 intrusion detection system (e.g., [6]) to identify and stop the 270 attacks. 272 2.2 Insider Attack Threats for SCSP 274 When an intruder has compromised a SCSP entity, such as the LS, it 275 can attack any other servers in the same Server Group. All 5 types of 276 outsider threats discussed in the previous sections can be exercised 277 by an insider. The worse part is that symmetric cryptographic 278 protocols is no longer effective in stopping these attacks. When the 279 attacker has full control of a SCSP entity, the compromised server's 280 behavior may seem just as normal to other members, if the intruder 281 tries to mimic the regular SCSP operation. Since the intruder is 282 trusted as a legitimate member in the group, it can legally access to 283 any resources in the Server Group. It is obvious that the Server 284 Group can easily be brought down even with implementation of strong 285 SCSP entity to entity authentication. One such example would be (to 286 be added) 288 One important objective in dealing with insider attacks is to have 289 the protocol robust enough such that the damages caused by a trusted 290 but compromised SCSP entity (insider attack) can be contained or 291 limited. Otherwise, the protocol is vulnerable to such insider 292 attack if insider attack's impact cannot be contained and has a 293 global bad impact on every other SCSP entities. The router black-hole 294 attack is one famous example of uncontained insider attack such that 295 a vicious router can cheat/trick directly or indirectly all the 296 routers to forward all their packets to this vicious node. Please 297 refer to [7] for more information about insider attacks on routing 298 protocols. 300 3. Security Measures for SCSP 301 This section presents security measures to protect normal SCSP 302 operation from security intrusions. 304 3.1 Server Access Control 306 SCSP server access control refers to the process of identifying 307 legitimate access request and enable information exchange between 308 local and authorized remote entities. Message exchange can happen 309 between SCSP entities (servers) and between protocol client and 310 server. This draft only limit to itself to SCSP message exchange. The 311 protocol client-server message is outside the scope of this draft. 312 For SCSP server access control, SCSP message authentication is 313 suggested and it will be discussed in the next section. Message 314 authentication guarantees that only legitimate remote SCSP entity can 315 exchange information with the local entity. Authentication failed 316 messages are flushed to protect the server from illegal access. 318 3.2 SCSP Message Authentication 320 As pointed out in Section 2.1, message authentication can provide 321 access control and is very important in detecting and preventing 322 message modification attack, and message sequencing attack when 323 combined with timestamp. 325 When authentication is used in SCSP messages, forged or modifies SCSP 326 messages fail authentication check and are not be honored. Only those 327 authenticated messages are processed. By flushing unauthorized 328 messages to servers which failed authentication, access control can 329 be maintained. 331 In current SCSP message definition, two types of authentication 332 methods can be used: clear-text password and HMAC-MD5-128 [8]. It is 333 obvious that cleartext password does not off much protection against 334 serious intruders. On the other hand, the HMAC-MD5-128 335 authentication mechanism between an LS and its DCSs provides a much 336 stronger means of protection for SCSP. The purpose of this 337 authentication is to verify that the the received messages are 338 actually coming from a trusted legitimate SCSP entity, rather than 339 from an attacker. 341 Furthermore, it is suggested that some kind of timestamp field be 342 incorporated into each SCSP message to protect from message replay 343 attack discussed in Section 2.1. In IPSEC document [9], a 32-bit 344 timestamp field is allocated to guarantee that each packet exchanged 345 between two parties is different. This 32-bit field is included in 346 the calculation of the authentication data. With the timestamp 347 contained in each SCSP message, replayed SCSP messages can be easily 348 detected and flushed. 350 Obviously, the use of authentication in SCSP messages increases the 351 processing overhead. However, since SCSP messages are used 352 infrequently to update server cache, authenticating SCSP messages 353 does not increase overall processing load much. Direct impact on 354 end-system performance is much less than authenticating data packets. 356 3.3 Secure Checksum enhancement 358 Currently, SCSP uses a simple standard IP checksum over the entire 359 SCSP packet. It has been pointed out that this type of checksum 360 mechanism used in OSPF may become a security weakness. The MaxAgeDiff 361 (Max Age Difference) attack in OSPFv2 is impossible if the checksum 362 were either MD5 or SHA. Since OSPF [14] and SCSP are similar in 363 operation, MD5 and SHA are suggested to offer a stronger secure 364 checksum mechanism. 366 4. Open Issues of SCSP Security 368 This section dealts with some of the open issues that related to SCSP 369 security, and also some possible security options that can be adopted 370 and implemented. 372 4.1 Protocol specific security concerns 374 The previous sections primarily focus on analyzing SCSP security 375 issues independent of any actual protocol the client-server is 376 running. Also current security measures a very basic security 377 service for all the SCSP applications to various client-server 378 protocols. However, SCSP has been designed to apply to different 379 applications, which might have their specific security requirements 380 and is outside the scope of this draft. 382 4.2 Possible adoption of IPSEC working group framework 384 The IETF security working group has proposed a set of network 385 security standards to offer a variety of security services. These 386 services include authentication [8], [9], [11], encapsulation payload 387 [12], and automatic key management [10]. It is suggested that SCSP 388 can re-use as much work as possible from the effort of IETF IPSEC 389 working group. 391 For example, the importance of payload encryption maybe depend on 392 data sensitivity of a particular protocol being synchronized by SCSP. 393 If there is a need for encryption, IETF IPSEC ESP protocol can be 394 adopted. 396 4.3 SCSP Digital Signature with Public Key Protocols 398 As discussed in Section 3.2, the HMAC MD5 authentication provide a 399 strong authentication for SCSP messages to guard against outsider 400 attack. However, when a SCSP entity is compromised, link to link 401 authentication such as the HMAC MD5 authentication can't prevent 402 these insider attacks. When a SCSP entity is compromised, the 403 attacker can potentially damage the SCSP infrastructure. This insider 404 problem has been identified in the OSPF community [7]. LSA (Link 405 State Advertisement) Digital Signature [14] has been proposed and 406 implemented to prevent such insider attacks. It is suggested that 407 SCSP adopt the same approach as OSPF by using digital signature to 408 sign the origination cache record. The digital signature can be 409 implemented as follows, 411 *SCSP_message, Sign(Originator's Private Key, MD5(SCSP_message)) 413 The details of using digital signature is beyond the scope of this 414 draft. Refer to RFC 2154 for the detailed scheme of using digital 415 signature for OSPFv2. 417 4.4 Key Management and Security Association Establishment 419 SCSP supports both manual and key management protocol for 420 distribution of secret keys. Manual key management is of limited 421 practical use, as it has a severe limitation of scalability. Many 422 automatic key management protocols have been proposed, for example, 423 ISAKMP/Oakley [10]. SCSP drafts suggest that any Internet standard 424 key management protocol MAY be used to negotiate the SPI and 425 parameters. 427 Further study (which is outside of the scope of this draft) is needed 428 to investigate how to use these standard key management protocol in 429 SCSP (instead of re-inventing a new key management protocol). 431 5. Conclusion 433 SCSP can be used to solve the generalized cache synchronization/cache 434 replication problem for distributed protocol entities. In a 435 client/server paradigm, SCSP synchronizes caches (or a portion of the 436 caches) of a set of server entities of a particular protocol which 437 are bound to a Server Group. This draft presents a security analysis 438 of running SCSP protocol. Both insider and outsider attack cases are 439 studied. Possible solution to these security threats are presented 440 and suggested. When SCSP is applied a specific protocol, additional 441 protocol dependent security analysis may be needed. 443 Acknowledgments 445 Reference 446 [1] "Server Cache Synchronization Protocol (SCSP)", J. Luciani, 447 G. Armitage, and J. Halpern, draft-ietf-ion-scsp-04.txt. 449 [2] "A Distributed NHRP Service Using SCSP", J. Luciani, 450 draft-ietf-ion-scsp-nhrp-05.txt. 452 [3] "A Distributed ATMARP Service Using SCSP", J. Luciani 453 draft-ietf-ion-scsp-atmarp-00.txt. 455 [4] "A Distributed MARS Service Using SCSP", J. Luciani, A. Gallo, 456 draft-ietf-ion-scsp-mars-01.txt 458 [5] "Freshness Assurance of Authentication Protocols", Kwok-Yan Lam, 459 Dieter Gollmann, ESORICS 92, November, 1992, pages 261-271 461 [6] "Architecture Design of a Scalable Intrusion Detection System 462 for the Emerging Network Infrastructure", F. Jou, F. Gong, C. 463 Sargor S. F. Wu, R. Cleaveland, MCNC Technical Report, April, 464 1997. Available under 466 http://www.mcnc.org/HTML/ITD/ANR/JiNao.html. 468 [7] "An Experimental Study of Insider Attacks for the OSPF Routing 469 Protocol", B. Vetter, F. Wang, S.F. Wu, IEEE International 470 Conference on Network Protocols (ICNP), October 1997, 471 pages 293-300. 473 [8] "HMAC: Keyed-Hashing for Message Authentication", 474 Krawczyk, H., Bellare, M., and R. Canetti, RFC 2104 476 [9] "HMAC-MD5-96 IP Authentication with Replay Prevention", M. 477 Oehler, R. Glenn, RFC 2085 479 [10] "Internet Security Association and Key Management Protocol 480 (ISAKMP)" Douglas Maughan, Mark Schertler, Mark Schneider, 481 Jeff Turner, draft-ietf-ipsec-isakmp-08.txt, 483 [11] "IP Authentication Header", Stephen Kent, Randall Atkinson, 484 draft-ietf-ipsec-auth-header-04.txt 486 [12] "IP Encapsulating Security Payload (ESP)", Stephen Kent, Randall 487 Atkinson, draft-ietf-ipsec-esp-v2-03.txt 489 [13] "OSPF Version 2", J. Moy, RFC 2178 491 [14] "OSPF with Digital Signatures", S. Murphy, M. Badger, 492 B. Wellington RFC 2154 494 Authors' Addresses 496 Cliff X. Wang 497 IBM, Networking Hardware Division 498 Dept. 0L4A/B664 499 P.O. Box 12195 500 Research Triangle Park, NC 27709 501 phone: +1-919-486-1255 502 email: cliff_wang@vnet.ibm.com 504 Felix Wu 505 North Carolina State University 506 Dept. of Computer Science 507 P.O.Box 7550 508 Raleigh, NC 27695 509 phone: +1-919-515-7920 510 email: wu@csc.ncsu.edu