idnits 2.17.1 draft-stillman-rserpool-threats-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 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 15 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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 337: '...security, implementations MUST support...' RFC 2119 keyword, line 344: '... implementations MUST support TLS with...' 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 (August 26, 2002) is 7886 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? 'RFC2026' on line 597 looks like a reference -- Missing reference section? 'WHYENC' on line 603 looks like a reference -- Missing reference section? 'ASAP' on line 605 looks like a reference -- Missing reference section? 'ENRP' on line 608 looks like a reference -- Missing reference section? 'SCTPIPsec' on line 611 looks like a reference -- Missing reference section? 'TLS' on line 614 looks like a reference -- Missing reference section? 'SCTPTLS' on line 616 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Maureen Stillman 2 INTERNET DRAFT Ram Gopal 3 Senthil Sengodan 4 Nokia 5 Erik Guttman 6 Sun Microsystems 7 Matt Holdrege 8 Sonus Networks 9 26 February 2002 10 expires August 26, 2002 12 Threats Introduced by Rserpool and Requirements for Security 13 in response to Threats 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 20 are working documents of the Internet Engineering Task Force (IETF), 21 its areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This Internet draft is an attempt to describe security threats 37 against the Rserpool protocol. This draft presents requirements for 38 a security solution to thwart these threats in environments where it 39 is likely to be deployed. The threats and requirements identified 40 herein and the document should be considered as work in progress. 42 Contents 44 Status of This Memo 1 45 Abstract 1 46 1. Introduction 3 47 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Threats 4 49 2.1 PE Registration/Deregistration flooding . . . . . . . . . 4 50 2.2 PE Registration/Deregistration flooding . . . . . . . . . 4 51 2.3 PE Registration/Deregistration spoofing . . . . . . . . . 4 52 2.4 PE Registration/Deregistration unauthorized . . . . . . . 5 53 2.5 Malicious ENRP server joins the group of legitimate ENRP 54 servers . . . . . . . . . . . . . . . . . 5 55 2.6 Registration/deregistration with malicious ENRP servers . 5 56 2.7 Malicious ENRP Name Resolution .. . . . . . . . . . . . . 5 57 2.8 Malicious node performs a replay attack.. . . . . . . . . 6 58 2.9 Re-establishing PU-PE security during failover. . . . . . 6 59 2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 61 2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 62 2.13 Application security . . . . . . . . . . . . . . . . . . 7 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 3.1 Scenarios for using TLS with Rserpool . . . . . . . . . . 8 65 3.1.1 PE - ENRP security . . . . . . . . . . . . . . . . . 9 66 3.1.1.1 Scenario A - TLS only . . . . . . . . . . . . . . 10 67 3.1.1.2 Scenario B - TLS plus alternate method for client 68 authentication . . . . . . . . . . . . . . . . . . 10 69 3.1.1.3 Open issues for ENRP-PE security . . . . . . . . . . 11 70 3.1.2 End user-ENRP security . . . . . . . . . . . . . . . . . 11 71 3.2 Scenarios for using IPsec with Rserpool . . . . . . . . . . 11 72 3.2.1 Scenario A - PU to ENRP server . . . . . . . . . . . . . 12 73 3.2.2 Scenario B - PE to ENRP server . . . . . . . . . . . . . 13 74 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 76 6. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 RSERPOOL provides a session layer for robustness and performance. The 80 session layer function may redirect communication transparently to 81 upper layers. This alters the direct one-to-one association between 82 communicating endpoints which typically exists between clients and 83 services. In particular, secure operation of protocols often relies 84 on assumptions at different layers regarding the identity of the 85 communicating party and the continuity of the communication between 86 endpoints. Further, the operation of RSERPOOL itself has security 87 implications and risks. The session layer is organized and operates 88 dynamically which imposes additional concerns for the overall security 89 of the end-to-end application. This document explores the security 90 implications of RSERPOOL, both due to its own functions and due to its 91 being interposed between applications and transport interfaces. 93 This draft is modeled after [MIPv6 threats] which is a threat analysis 94 document for Mobile IP V6. 96 1.1 Definitions 98 This document uses the following terms: 100 ENRP Endpoint Name Resolution Protocol: 101 Within the operational scope of Rserpool, ENRP defines the 102 procedures and message formats of a distributed fault-tolerant 103 registry service for storing, bookkeeping, retrieving, and 104 distributing pool operation and membership information. 106 ASAP Aggregate Server Access Protocol: 107 A session layer protocol which uses the Endpoint Name 108 Resolution Protocol (ENRP) to provide a high 109 availability name space. ASAP is responsible for the 110 abstraction of the underlying transport technologies, load 111 distribution management,fault management, as well as the 112 presentation to the upper layer (i.e., the ASAP user) a 113 unified primitive interface. 115 Operation scope: 116 The part of the network visible to pool users by a specific 117 instance of the reliable server pooling protocols. 119 Pool (or server pool): 120 A collection of servers providing the same application 121 functionality. 123 Pool handle (or pool name): 124 A logical pointer to a pool. Each server pool will be 125 identifiable in the operation scope of the system by a unique 126 pool handle or "name". 128 ENRP namespace (or namespace): 129 A cohesive structure of pool names and relations that may be 130 queried by an internal or external agent. 132 Pool element (PE): 133 A server entity that runs ASAP and has registered to a pool. 135 Pool user (PU): 136 A server pool user that runs ASAP. Note, a PU can also be a 137 PE if it has registered itself to a pool. 139 ENRP namespace server (or ENRP server): 140 Entity which runs ENRP and is responsible for managing and 141 maintaining the namespace within the operation scope. 143 2. Threats 145 2.1 PE Registration/Deregistration flooding 147 Threat: A malicious node could send a stream of false 148 registrations/deregistrations on behalf of non-existent PEs to ENRP 149 servers at a very rapid rate and thereby create unnecessary state in an 150 ENRP server. 152 Effect: Corrupting the name server database and/or disabling the 153 Rserpool discovery and naming function. 155 Requirement: An ENRP server that receives a registration/deregistration 156 should not create or update state information until it has authenticated 157 the PE. 159 2.2 PE Registration/Deregistration flooding 161 Threat: A malicious node or PE could send a stream of 162 registrations/deregistrations that are unauthorized to 163 register/deregister - to ENRP servers at a very rapid rate and thereby 164 create unnecessary state in an ENRP server. 166 Effect: Corrupting the name server database and/or disabling the 167 Rserpool discovery and naming function. 169 Requirement: An ENRP server that receives a registration/deregistration 170 should not create or update state information until the authorization of 171 the registering/de-registering entity is verified. 173 2.3 PE Registration/Deregistration spoofing 175 Threat: A malicious node could send false registrations/deregistrations 176 to ENRP servers concerning a legitimate PE thereby creating false state 177 information in the ENRP servers. 179 Effect: Misinformation in the ENRP server concerning a PE would get 180 propagated to other ENRP servers thereby corrupting the ENRP database. 182 Requirement: An ENRP server that receives a registration/deregistration 183 should not create or update state information until it has authenticated 184 the PE. 186 2.4 PE Registration/Deregistration unauthorized 188 Threat: A PE who is not authorized to join a pool could send 189 registrations/deregistrations to ENRP servers thereby creating false 190 state information in the ENRP servers. 192 Effect: Misinformation in the ENRP server concerning a PE would get 193 propagated to other ENRP servers thereby corrupting the ENRP database. 195 Requirement: An ENRP server that receives a registration/deregistration 196 should not create or update state information until it has authorized 197 the requesting entity. 199 2.5 Malicious ENRP server joins the group of legitimate ENRP servers 201 Threat: Malicious ENRP server joins the group of legitimate ENRP servers 202 with the intent of propagating inaccurate updates to corrupt the ENRP 203 database. 205 Effect: Inconsistent ENRP database state. 207 Requirement: Mutual authentication of ENRP servers. 209 2.6 Registration/deregistration with malicious ENRP server 211 Threat: A PE unknowingly registers/deregisters with malicious ENRP 212 server. 214 Effect: Registration might not be properly processed or ignored. 216 Requirement: PE needs to authenticate the ENRP server. 218 2.7 Malicious ENRP Name Resolution 220 Threat: The ASAP protocol receives a name resolution response from an 221 ENRP server, but the ENRP server is malicious and returns random IP 222 addresses or an inaccurate list in response to the pool handle. 224 Effect: PU application communicates with the wrong PE or is unable to 225 locate the PE since the response is incorrect in saying that a PE with 226 that name did not exist. 228 Requirement: ASAP needs to authenticate the ENRP server. 230 2.8 Malicious node performs a replay attack 232 Threat: A malicious node could replay the entire message previously sent 233 by a legitimate entity. This could create false/unnecessary state in the 234 ENRP servers when the replay is for registration/de-registration or 235 update. 237 Effect: False/extra state is maintained by ENRP servers 239 Requirement: Care should be taken to prevent replay attacks. 241 2.9 Re-establishing PU-PE security during failover 243 Threat: PU fails over from PE A to PE B. In the case that the PU had a 244 trusted relationship with PE A, then the PU will likely not have the 245 same relationship established with PE B. 247 Effect: If there was a trust relationship involving security context 248 between PU and PE A, the equivalent trust relationship will not exist 249 between PU and PE B. This will violate security policy. 251 Requirement: Either notify the application when fail over occurs so the 252 application can take appropriate action to establish a trusted 253 relationship with PE B OR reestablish the security context 254 transparently. 256 2.10 Integrity 258 Threats: 259 a) ENRP response to name resolution is corrupted during transmission 260 b) ENRP peer messages are corrupted during transmission 261 c) PE sends update for values and that information is corrupted during 262 transmission 264 Effect: ASAP receives corrupt information for pool handle resolution 265 which the PU believes to be accurate. 267 Requirement: Integrity mechanism needed. 269 2.11 Data Confidentiality 271 Threat: An eavesdropper capable of snooping on fields within messages in 272 transit, may be able to garner information such as topology/location/IP 273 addresses etc. that may not be desirable to divulge. 275 Effect: Information that an administrator does not wish to divulge are 276 divulged. 278 Requirement: Provision for Data confidentiality service. 280 2.12 ENRP Server Discovery 282 Threat A thwarting successful discovery: When a PE wishes to register 283 with an ENRP server, it needs to discover an ENRP server. An attacker 284 could thwart the successful discovery of ENRP server(s) thereby inducing 285 the PE to believe that no ENRP server is available. For instance, the 286 attacker could reduce the returned set of ENRP servers to null or a 287 small set of inactive ENRP servers. 289 Threat B: A similar thwarting scenario also applies when an ENRP server 290 or ASAP on behalf of a PU needs to discover ENRP servers. 292 Threat C: Spoofing successful discovery: An attacker could spoof the 293 discovery by claiming to be a legitimate ENRP server. When a PE wishes 294 to register, it finds the spoofed ENRP server. 296 Threat D: A similar spoofing scenario also applies when an ENRP server 297 or ASAP on behalf of a PU needs to discover ENRP servers. 299 Effect A: A PE that could have been in an application server pool does 300 not become part of a pool. The PE does not complete discovery operation. 301 This is a DOS attack. 303 Effect B: An ENRP server that could have been in an ENRP server pool 304 does not become part of a pool. A PU is unable to utilize services of 305 ENRP servers. 307 Effect C,D: This malicious ENRP would either misrepresent, ignore 308 or otherwise hide or distort information about the PE to subvert 309 RSERPOOL operation. 311 Requirement: Discovery phase needs to be authenticated. 313 2.13 Security State for Applications 315 The security context of an application is a subset of the overall 316 context, and context or state sharing is explicitly out-of-scope for 317 RSerPool. Because RSerPool does introduce new security vulnerabilities 318 to existing applications application designers employing RSerPool should 319 be aware of problems inherent in failing over secured connections. 320 Security services necessarily retain some state and this state may have 321 to be moved or re-established. Examples of this state include 322 authentication or retained ciphertext for ciphers operating in cipher 323 block chaining (CBC) or cipher feedback (CFB) mode. These problems must 324 be addressed by the application or by future work on RSerPool. 326 Requirement: None at this time. Future Rserpool work may address this 327 issue. 329 3. Security Considerations for Rserpool 331 Due to varying requirements and multiple use cases of Rserpool, we point 332 out two basic security protocols, IPsec and TLS. We specifically 333 do not discuss whether one security protocol would be preferred over the 334 other. This choice will be made by designers and network 335 architects based on system requirements. 337 For networks that demand IPsec security, implementations MUST support 338 draft-ietf-ipsec-sctp-02.txt which describes IPsec-SCTP. IPsec is 339 two layers below RSerPool. Therefore, if IPsec is used for securing 340 Rserpool, no changes or special considerations need to be made to 341 Rserpool to secure the protocol. 343 For networks that cannot or do not wish to use IPsec and prefer instead 344 TLS, implementations MUST support TLS with SCTP as described in 345 draft-ietf-tsvwg-tls-over-sctp-00.txt or TLS over TCP as described in 346 RFC 2246. When using TLS/SCTP we must ensure that RSerPool does 347 not use any features of SCTP that are not available to an TLS/SCTP user. 348 This is not a difficult technical problem, but simply a 349 requirement. When describing an API of the RSerPool lower layer we have 350 also to take into account the differences between TLS and SCTP. 351 This is also not difficult, but it is in contrast to the IPsec solution 352 which is transparently layered below Rserpool. 354 Support for security is required for the ENRP server and the PEs. 355 Security support for the Rserpool end user is optional. Note that 356 the end user implementation contains a piece of the Rserpool protocol -- 357 namely ASAP -- whereby the pool handle is passed for name 358 resolution to the ENRP server and IP address(es) are returned. 360 The argument for optional end user security is as follows: If the user 361 doesn't require security protection for example, against 362 eavesdropping for the request for pool handle resolution and response, 363 then they are free to make that choice. However, if 364 the end user does require security, they are guaranteed to get it due to 365 the requirement for security support for the ENRP server. 366 It is also possible for the ENRP server to reject an unsecured request 367 from the user due to its security policy in the case that it 368 requires enforcement of strong security. But this will be determined by 369 the security requirements of the individual network design. 371 3.1 Scenarios for using TLS with Rserpool 373 This section describes security scenarios for two different parts of the 374 Rserpool protocol. First, we examine the interaction between the PE 375 and ENRP server. Next we examine a scenario for the end user (client 376 using ASAP) and ENRP server interaction. 378 Security provided by TLS includes authentication, confidentiality, 379 integrity, protection from replay attack and protection from downgrade 380 attack (that is coercing the server to go with a weaker ciphersuite than 381 the client-server together can support). 383 TLS features: ciphersuites are comprised of a triple (key exchange 384 algorithm WITH encryption algorithm, MAC algorithm). 385 The ciphersuite is negotiated between the client and server with the 386 server choosing the ciphersuite. This negotiation allows new cipher 387 suites to be easily incorporated once they are standardized (example: 388 AES) and old ones to be dumped when they are shown to be 389 easily cracked. Confidentiality is optional meaning the second 390 parameter can be null. A cipher suite of NULL WITH NULL NULL 391 is deprecated (meaning don't do it). It offers no security. Once you 392 have successfully negotiated a TLS connection, TLS allows you 393 to resume sessions at a later time if the server is willing to do so. 394 How long a session can be around before it can not be resumed 395 is a matter of local policy. Session resumption saves on performance 396 (CPU cycles) and handshake messages. 398 Assumptions: 400 (1) Each ENRP name server possesses a certificate (probably X.509 v3) 401 signed by a CA and an associated private key. This allows the 402 server to validate itself as a legitimate ENRP server for the domain 403 foo.bar.com. It will contain this domain name in the certificate 404 to allow the PE to check this against it's DNS inquiry. 406 (2) PEs may authenticate using TLS, SRP or some other authentication 407 protocol. We could have each PE use TLS and supply a client certificate 408 but this might not scale well. Therefore, I have suggested other 409 authentication mechanisms for PE to ENRP server. 411 3.1.1 PE - ENRP security 413 TLS is a client-server protocol and the client and server play different 414 roles. In this scenario the PE functions as the TLS client and 415 ENRP functions as the TLS server. We describe two different TLS 416 scenarios in this section to enforce PE - ENRP security. 418 For scenario A ENRP and PE use TLS for mutual authentication. In 419 scenario B, ENRP servers authenticate themselves using TLS and PEs 420 authenticate themselves using some other unspecified authentication 421 mechanism. This scenario will allow either TCP or SCTP as the transport 422 for TLS. However, the current consensus is that the PEs should use SCTP 423 to communicate with the (ENRP) name server 424 3.1.1.1 Scenario A -- TLS only 426 1) PE wants to register with a ENRP server. Uses DNS to lookup 427 foo.bar.com ENRP server. 428 2) Establish a TLS connection with ENRP server. Negotiate chiphersuite. 429 3) PE (client) Gets the ENRP server certificate as part of the TLS 430 protocol. 431 a) Validate the signature; 432 b) check expiration date; 433 C) OCSP to check if the certificate has been revoked 434 d) check the certificate contents name against the dns FQDM. 435 3) Get the client (PE) certificate as part of the TLS protocol. 436 a) Validate the signature; 437 b) check expiration date; 438 C) OCSP to check if the certificate has been revoked 439 d) check the cert contents against what? (This is a problem) 440 If any checks fail, send back error message (defined by TLS) and abort. 441 4) TLS session is now established with mutual authentication of the PE 442 and ENRP 443 server 444 5) PE Sends registration message with pool handle name using TLS session 445 6) ENRP will either authorize that PE to join that pool or ask a third 446 party (such as AAA) to authorize 448 3.1.1.2 Scenario B -- TLS plus alternate method for PE (client) 449 authentication 451 1) PE wants to register with a ENRP server. Uses DNS to lookup 452 foo.bar.com ENRP server. 453 2) Establish a TLS session with ENRP server. Negotiate chiphersuite. 454 3) Get the ENRP server cert as part of the TLS protocol. 455 a) Validate the signature; 456 b) check expiration date; 457 C) OCSP to check if the cert has been revoked 458 If any checks fail, send back error message (defined by TLS) and abort. 459 4) TLS session is now established with au thentication of the ENRP 460 server 461 5) authenticate the client -- using the established TLS session, perform 462 client authentication mechanism using SRP, CHAP, etc. 463 6) If client auth fails, then the server terminates the TLS session 464 7) TLS session is now established with mutual authen of the PE and ENRP 465 server 466 8) PE Sends registration message with pool handle name using TLS session 467 9) ENRP will either authorize that PE to join that pool or ask a third 468 party to authorize. 470 3.1.1.3 Open issues for ENRP-PE security 472 1) Order of authentication -- ENRP server first, PE client second OR PE 473 client first then ENRP server 475 Should we authenticate the PE (client) first and then set up the TLS 476 connection if the authentication of the PE is oK or vice versa? 477 ENRP - PE 478 Advantages: PE knows it is talking with a genuine name server quickly. 479 The other way would take longer for it to figure out it was 480 talking with a bogus ENRP. The malicious ENRP could accept its 481 authentication credentials and only later it would find out the ENRP 482 server is not legitimate. This would waste time. 483 PE - ENRP 484 Disadvantage - Alternatively, malicious ENRP server could just reject 485 its authen credentials and the PE would never find out that it 486 was talking with the "bad" ENRP server. 488 Conclusion: Authenticate ENRP server first, then the PE (client). 490 2) Do we allow authentication but no confidentiality in PE - ENRP 491 communications? 492 This is supported by TLS. If we want Authentication but no 493 confidentiality, use TLS cipher suite: 494 key exchange algorithm WITH no encryption algorithm, MAC algorithm i.e., 495 xxx WITH NULL, yyy 497 3.1.2 End user-ENRP security 499 For this scenario, we only need to authenticate the ENRP server. 500 Presumably, any end user can contact the name server. 501 In this scenario the end user functions as the TLS client and ENRP 502 functions as the TLS server. 504 1) Using ASAP the end user wants to resolve a name using ENRP server. 505 Uses DNS to lookup foo.bar.com ENRP server. 506 2) Establish a TLS session with ENRP server. Negotiate chiphersuite. 507 3) Get the ENRP server cert as part of the TLS protocol. 508 a) Validate the signature; 509 b) check expiration date; 510 C) OCSP to check if the cert has been revoked 511 If any checks fail, send back error message (defined by TLS) and abort. 512 4) TLS session is now established with authen of the ENRP server 513 Send request for name/address resolution using TLS session; get response 514 5) We can resume this session if local policy allows it (the ENRP server 515 policy, that is) 517 3.2 Scenarios for using IPsec with Rserpool 519 This scenario works with any transport protocol, although TCP or SCTP 520 are strongly recommended. 522 3.2.1 Scenario A PU to ENRP server 524 To pre-establish one/more alternative IPSec security associations 525 (SA) that can be used should the primary SA become unusable (due to 526 server failure). No context sharing is done between SAs that are 527 terminated at the different servers. 529 PU ENRP1 ENRP2 530 ==== ==== ==== 531 IP SA1 -----------------SAa IP /SA* IP 532 SA2 --------------------------+ 534 In this case PU has a separate SA with ENRP1 and ENRP2, call them SA1 535 and SA2. In this case, the transport and RSERPOOL interactions, as well 536 as the application data is (a) protected (b) authenticated by IPsec. 537 I call the SAs by different names on the PE sides since its important 538 to note the problem is symmetric - you need association to be built 539 from each ENRP server back to each pool user. 541 The issue I see with this approach is the coordination between the 542 rserpool layer and the IPsec layer. In particular, you need to 543 establish n SAs for each PU, where n is the number of ENRP servers. 544 This need not be done immediately: There's the usual trade off of 545 eager/lazy processing. 547 Since this is network layer security, a break in the flow of 548 communication can be handled by the transport layer. The security state 549 associated with the IPsec communication flow can be initialized and 550 established with a different flow - to a different agent, in the case 551 where RSERPOOL decides to redirect traffic. The challenge is still at 552 the higher layers - doing application state context transfer. 553 However, since these name resolution messages don't rely on state, we 554 can just resend the messages in the event of failure of an ENRP server. 556 Time 557 | PU ENRP1 ENRP2 558 v ==== ===== ===== 559 A! 560 o----- 561 \ 562 -----> 563 B -----o SA(x) 564 / 565 SA(x)<---- C 566 <======> 568 D! 569 o------------------ 570 \ 571 -----> 572 E -----o SA(y) 573 / 574 SA(y)<----------------- F 575 <=======================> 577 A! RSERPOOL decides to direct PU traffic to ENRP1 578 B Establish SA and associated state between PU and ENRP1 579 (like cypher block vectors) 580 C Communicate between PU and ENRP1. Stateful changes to SA(x) state 581 continue to occur on both sides of the communication. 582 D! RSERPOOL decides to redirect PU traffic to PE2 583 Note that a distinct SA must be established between PU and ENRP2. 584 The entire state between PU and ENRP1 can be tossed, or saved for 585 future communication between PU and ENRP1. 586 E Establish SA and associated state between PU and ENRP2 587 F Communicate between PU and ENRP2. Stateful changes to SA(y) state 588 continue to occur on both sides of the association. 590 3.2.2 Scenario B - PE to ENRP server 592 There is no technical difference in Scenario A and B. The names are 593 just changed, that is, substitute PE for PU. 595 4. References: 597 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 598 RFC 2026, October 1996. 600 [MIPv6 threats] draft-team-mobileip-mipv6-sec-reqts-00.txt, July, 2001, 601 work in progress. 603 [WHYENC] draft-ietf-saag-whyenc-00.txt, July 2001, work in progress. 605 [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol 606 (ASAP)", , work in progress. 608 [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", 609 draft-ietf-rserpool-enrp-00.txt, work in progress. 611 [SCTPIPsec] On the use of SCTP with IPsec 612 draft-ietf-ipsec-sctp-02.txt, work in progress. 614 [TLS] TLS Version 1.0, RFC 2246. 616 [SCTPTLS] SCTP over TLS 617 draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. 619 5. Acknowledgements 621 Thanks to the Rserpool security design team that provided valuable 622 comments. Lyndon Ong, Randy Stewart, Qiaobing Xie, Michael Tuexen, 623 Sohrab Modi, Javier Pastor-Balbas, Xingang Guo, M. Piramanayagam, 624 Bernard Aboba and Dhooria Manoj. 626 expires August 26, 2002 628 6. Author's Addresses 630 Ram Gopal 631 Nokia Research Center 632 5 Wayside Road 633 Burlington, MA 01803 634 USA 635 email: ram.gopal@nokia.com 637 Erik Guttman 638 Sun Microsystems 639 Eichhoelzelstr. 7 640 74915 Waibstadt 641 Germany 642 Email: Erik.Guttman@sun.com 644 Matt Holdrege 645 Sonus Networks 646 223 Ximeno Avenue 647 Long Beach, CA 90803 648 matt@sonusnet.com 650 Senthil Sengodan 651 Nokia Research Center 652 5 Wayside Road 653 Burlington, MA 01803 654 USA 655 email: Senthil.sengodan@nokia.com 657 Maureen Stillman 658 Nokia 659 35 Woodcrest Ave. 660 Ithaca, NY 14850 661 USA 662 email: maureen.stillman@nokia.com