idnits 2.17.00 (12 Aug 2021) /tmp/idnits12829/draft-fajardo-dime-base-test-suite-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 13, 2009) is 4688 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME V. Fajardo 3 Internet-Draft Telcordia Technologies 4 Expires: January 14, 2010 A. McNamee 5 Openet-Telecom 6 H. Tschofenig 7 Nokia Siemens Networks 8 J. Bournelle 9 France Telecom R&D 10 July 13, 2009 12 Diameter Base Protocol Interoperability Test Suite 13 draft-fajardo-dime-base-test-suite-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2010. 38 Copyright Notice 40 Copyright (c) 2009 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 in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes a collection of test cases to be used for 52 Diameter base protocol interoperability testing. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Diameter Base Protocol Test Suite . . . . . . . . . . . . . . 3 59 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1.1. Connectivity and Peering . . . . . . . . . . . . . . . 3 61 3.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.3. Relay Agent . . . . . . . . . . . . . . . . . . . . . 10 63 3.1.4. Redirection Agent . . . . . . . . . . . . . . . . . . 10 64 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.2.1. General Statemachine . . . . . . . . . . . . . . . . . 10 66 3.2.2. Dynamic Peer Discovery . . . . . . . . . . . . . . . . 11 67 4. Diameter Base Protocol Application Support . . . . . . . . . . 11 68 4.1. Authentication and/or Authorization . . . . . . . . . . . 11 69 4.1.1. Stateful Session . . . . . . . . . . . . . . . . . . . 11 70 4.1.2. Stateless Session . . . . . . . . . . . . . . . . . . 12 71 4.2. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.2.1. Client Session . . . . . . . . . . . . . . . . . . . . 12 73 4.2.2. Server Session . . . . . . . . . . . . . . . . . . . . 13 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The document is meant to aid in the identifying the functional test 82 cases of a Diameter implementation. The Diameter interoperability 83 test suites are categorized by required and optional functionality. 84 The required functionality is the baseline capability that an 85 implementation must support to allow basic interoperability for that 86 category. Optional functionality covers features that not all 87 implementations support or may wish to test. This document also 88 covers test suites for common application support provided by the 89 diameter base protocol. 91 At its current state, this document provides only a collection of 92 test cases designed for interoperability. Test plans may be included 93 in future revisions of this work or maybe provided in some other 94 document. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 Within this document the terms defined in [RFC2119] refer to the 103 functionality that has to be provided by an implementation for the 104 usage within this interoperability test document. 106 3. Diameter Base Protocol Test Suite 108 All implementation must conform to [RFC3588]. 110 3.1. Required 112 3.1.1. Connectivity and Peering 114 Implementations must conform to Section 5.6 of [RFC3588]. Typical 115 test topology for statemachine test uses peer pairs as shown in 116 Figure 1. It is left to the testers if one-to-many or many-to-one 117 connections will be performed to test scalability and loading. The 118 test cases described below references Figure 1 below. 120 +--------+ +--------+ 121 |Vendor A|<---wired link---->|Vendor B| 122 +--------+ +--------+ 123 Figure 1: Peer Statemachine Test Topology 125 3.1.1.1. Capabilities Negotiation 127 Implementations must be able to perform at least the following 128 behavior described in Section 5.3 of [RFC3588]. 129 o Positive test for establishment of connection with test pairs 130 advertising support for common application ids (auth, accounting 131 or vendor). Vendor A initiates transport connection to B and 132 trigger the process. 133 o Positive test for establishment of connection with test pairs of 134 which one of them is advertising support for only relay app and no 135 other app is in common. 136 o Positive test for establishment of connection advertising the 137 relay app in auth app id, acct app id & VSA. 138 o Positive test for establishment of connection with test pairs 139 advertising support common transport security, specifically the 140 use of TLS and/or IPSec. It is left up to the participants to 141 generate appropriate keys and certificates specific for this test. 142 Vendor A initiates transport connection to B and trigger the 143 process and advertised proper Inband-Security support. 144 o Positive test for DWR/DWA exchange after connection is 145 established. Vendor A and B both exchange watchdogs as per 146 Section 3.4.1 of [RFC3539]. 147 o Negative test where DIAMETER_NO_COMMON_APPLICATION is returned by 148 a peer with no common application id (auth, accounting or vendor). 149 Intentionally configure vendor A not to advertise any 150 applications, different applications than B or vendor id's known 151 only to A. 152 o Negative test where DIAMETER_NO_COMMON_SECURITY is returned by a 153 peer with no common application id. Intentionally configure 154 vendor A to send Inband-Security-AVP with value 1 (TLS) that B 155 will not support. 156 o Negative test for unknown peers. Use of DIAMETER_UNKNOWN_PEER or 157 silent discard to disconnect unknown peers. Intentionally 158 configure vendor A to send an origin-host that is not in B's peer 159 table. 160 o Negative test case for TLS handshake failure. In the case where 161 the negotiated Inband-Security involves subsequent TLS 162 negotiation, participants can simulate a TLS handshake failure 163 (i.e. via invalid certificates, TLS/SSL version mis-match etc) 164 that must result in the peers being disconnected. 165 Verification of each test result can be done manually. 167 3.1.1.2. Election 169 This test case refers to Section 5.6.4 of [RFC3588]. Responders must 170 be able to resolve contention with initiator peers. 172 o Positive test for establishment of connection with responder 173 having higher identity than initiator. Vendor A initiates 174 connection followed by B doing the same a few milliseconds later. 175 Vendor A having a higher identity should close B's connection 176 attempt. 177 o Positive test for disconnection with initiator having lower 178 identity than the responder. Vendor A initiates a connection 179 followed by B doing the same a few milliseconds later. Vendor A 180 having a lower identity should close its initial connection 181 attempt. 182 o Negative test for disconnection when initiator and responder have 183 equal identity. Vendor A and B will advertise the equal identity. 184 Verify that both peers closed the connection. 185 Verification of test results can be done manually. 187 3.1.1.3. Disconnection 189 Implementations must conform to Section 5.6.4 of [RFC3588] and 190 Section 3.4.1 of [RFC3539]. Peers must be able to quickly determine 191 disconnection events. Verification of test results can be done 192 manually. 193 o Positive test for peer disconnection using DPR/DPA exchange. 194 Vendor A initiates shutdown while connected to B. Implementations 195 behavior may vary depending on disconnection cause such as an 196 eventual connection retry if a disconnection cause of REBOOTING is 197 received. 198 o Positive test for detecting disconnection via system level events 199 (i.e., transport resets, socket error, system link-down signals, 200 etc). Implementation must be able to initiate failover procedure. 201 Implementation should also attempt re-connection with lost peer. 202 Hard disconnection of vendor A and B's wired link can be done to 203 simulate this scenario. 204 o Positive test for detecting disconnection via watchdog timeout. 205 If there is no activity after a watchdog timer expires with 206 pending request then the peer becomes suspect and implementation 207 must be able to initiate failover procedure. [RFC3539] suggest a 208 minimum watchdog timeout at 6 sec. Vendor B can setup a transport 209 level filter to silently drop AAA traffic from B to simulate 210 unresponsiveness of B. 211 o Positive test for resetting connection after at least two(2) 212 watchdog has expired. If a connection is already suspect, the 213 peers must reset the connection. Vendor A or B can setup a 214 transport level filter to silently drop AAA traffic and simulate 215 unresponsiveness of both peers. 216 Verification of test results can be done manually. 218 3.1.1.4. Re-Connection Algorithms 220 Implementations must conform to Section 2.1 of [RFC3588]. Although a 221 vendor can implement other algorithms and policies than those 222 proposed in [RFC3588], a default reconnection scheme must be 223 implemented. 224 o Positive test for peer re-connection after disconnection has been 225 detected. The link between vendor A and B is temporarily 226 disconnected until such time that disconnection is detected by 227 both peers. The link can then be restored to test the re- 228 connection behavior of both peers. Verify that at least three(3) 229 watchdog exchanges occur before both peers are no longer suspect. 231 3.1.1.5. Failover and Failback 233 Implementations must conform to Section 5.4.5 of [RFC3588] and 234 Section 3.4.2 of [RFC3539]. Testing failover mechanism requires 235 alternate peer connections. A basic ring topology to test failover 236 and failback is shown in Figure 2 where vendor A has a primary route 237 to vendor C via vendor B and secondary route via vendor D. The same 238 symmetry is applied to all other vendors. As an example, vendor C 239 has a symmetric topology where D is its primary connection and B is 240 its secondary. This allows the same tests to be performed for all 241 vendors. For testing failover on vendor A and B, link0 can be 242 disconnected. For vendor C and D, link2 can be disconnected and so 243 on. 245 +---------+ 246 |Vendor B | 247 +---------+ 248 / \ 249 link0 link3 250 +---------+/ \+---------+ 251 |Vendor A | |Vendor C | 252 +---------+\ /+---------+ 253 link1 link2 254 \+---------+/ 255 |Vendor D | 256 +---------+ 258 Figure 2: Failover Test Topology 260 The enumerated test cases refers only to vendor A but can be applied 261 to any of the vendor implementations in Figure 2. Conditions for a 262 positive test requires that realm routes to C is present in A and 263 host routing is not used. Initial traffic should flow from A to C 264 via B (as the primary peer of A). 266 o Positive test for failover when link0 is disconnected. Vendor A 267 should have pending requests queued prior to disconnection. Upon 268 disconnection (see Section 3.1.1.3), verify that the pending 269 request with T-flag set has been forwarded to C via D. 270 o Positive test for failover by using device watchdog as a means of 271 triggering link0 disconnection. Vendor A should have pending 272 requests queued prior to disconnection. Upon disconnection (see 273 Section 3.1.1.3), verify that the pending request with T-flag set 274 has been forwarded to C via D. 275 o Positive test for failback when link0 is restored and re- 276 connection succeeds (See Section 3.1.1.4). Verify that new 277 request message is routed back to B. 278 o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answer 279 message from B to A when Destination-Host is set to C. This can be 280 simulated when link3 is disconnected and Vendor C is not reachable 281 from Vendor. Note that alternate path via Vendor D should not be 282 used. 283 o Negative test to detect duplicate messages on C. Vendor B can 284 disable watchdog processing but still allow request message 285 forwarding. This makes B a suspect peer from A and trigger 286 failover procedure. Forwarding of queue request will then be done 287 through D. However, the original request messages would have 288 reached C via B. 290 3.1.2. Routing 292 Implementation must conform to Section 6 of [RFC3588]. A basic 293 topology to test Diameter routing is shown in Figure 3 where vendor A 294 and vendor B can deploy two(2) Diameter peers to test host, realm and 295 answer message routing. Vendor A1 and A2 shares the same realm 296 (realmA). Vendor B1 and B2 share a different realm (realmB). Test 297 between both realms are symmetric although the description focuses 298 mostly to vendor A for editorial reasons. The topology is also 299 designed so that multi-hop forwarding, message loopback and agent 300 configuration can be tested. Note that some test cases in this 301 section require link disconnection overlap with the test cases 302 outline in Section 3.1.1.3. An implementation experiencing link 303 disconnection must update its peer and realm route table accordingly. 304 Verification for usage of proper routing AVPs in Section 6.7 of 305 [RFC3588] must be done when testing routing functionality. 307 +---------+ 308 |Vendor A2| (realmA) 309 +---------+ 310 / | \ 311 (realmA) link1 | link2 312 +---------+/ | \+---------+ 313 |Vendor A1| link0 |Vendor B2| (realmB) 314 +---------+\ | /+---------+ 315 link4 | link3 316 \+---------+/ 317 |Vendor B1| 318 +---------+ 319 (realmB) 321 Figure 3: Routing Test Topology 323 3.1.2.1. Peer Based Request Routing 325 Implementation must conform to Section 6.1.5 of [RFC3588]. In order 326 to perform the test cases the peer requesting the AAA routing must 327 have the destination-host and the destination-realm present in the 328 request message. 329 o Positive test for request forwarding from originator. Request 330 messages generated from A1 should reach B2 via B1 if destination- 331 host of the request is B2 and destination-realm is realmB and all 332 links are up. A1 must perform realm routing to reach B1 and B1 333 must perform forwarding to reach B2. Verification of routing can 334 be done manually if message has reached B2 via link4 and link3. 335 o Positive test for multi-hop request forwarding. Request messages 336 generated from A1 with destination-host B2 and destination-realm 337 realmB should reach B2 via A2 and B1 if all links are up except 338 for link4 and link2. A1 and A2 must perform realm routing while 339 B1 performs forwarding. A1 and A2 must be able to route the 340 request message to B1 even if it does not have B2 in its peer 341 table. Verification of routing can be done manually if message 342 has reached B2 via link1, link0 and link3. 343 o Negative test for request forwarding. If a request message 344 generated from A1 has a destination-host B2 and destination-realm 345 realmB with all links up except for link0, link2 and link4 then A2 346 must send an answer message to A1 with result-code 347 DIAMETER_UNABLE_TO_DELIVER. Verification can be done manually if 348 the answer message has reached A1 with E-bit set. 350 3.1.2.2. Realm Based Routing 352 Implementation must conform to Section 6.1 and Section 6.1.6 of 353 [RFC3588]. Test cases for realm-based request routing must have 354 destination-realm present but must not have destination-host present 355 in the request message. Note that there is some test overlap with 356 the test cases defined in Section 3.1.2.1. 357 o Positive test for request routing from originator. Request 358 messages generated from A1 should reach B2 via B1 if the 359 destination-realm is realmB and all links are up. A1 and B1 must 360 perform realm routing to reach B2. The request must have an id 361 (app, auth or vendor) that B1 must route and B2 must process 362 locally. Verification of routing can be done manually if message 363 has reached B2 via link4 and link3. 364 o Positive test for multi-hop request routing. Request messages 365 generated from A1 with destination-realm realmB should reach B2 366 via A2 and B1 if all links are up except for link4 and link2. A1, 367 A2 and B1 must perform realm routing. The request must have an id 368 (app, auth or vendor) that A1, A2 and B1 must route and B2 must 369 process locally. Verification of routing can be done manually if 370 message has reached B2 via link1, link0 and link3. 371 o Negative test for request routing. If a request message generated 372 from A1 has a destination-realm realmB with all links up except 373 for link0, link2 and link4 then A2 must send an answer message to 374 A1 with result-code DIAMETER_UNABLE_TO_DELIVER. Verification can 375 be done manually if the answer message has reached A1 with E-bit 376 set. 378 3.1.2.3. Answer Message Routing 380 Implementations must conform to Section 6.2 of [RFC3588]. Answer 381 routing can be verified using test cases in Section 3.1.2.1 and 382 Section 3.1.2.2. 384 3.1.2.4. Loop Detection 386 Implementation must conform to Section 6.1.3 of [RFC3588]. All 387 forwarders must verify that their local identity is not present in 388 the route-record of the request. If it is present, the forwarder 389 must send an answer with result-code DIAMETER_LOOP_DETECTED. If it 390 is not present, implementations must also insert route-records into 391 the request messages. 392 o Positive test for loop detection can be done if a request 393 originating from A1 has a destination-realm realmA and A1 is 394 configure to route request for realmA to A2, A2 will route request 395 for realmA to B1 and B1 will route request back to A1. Though A1 396 originated the request, it must be able to send an answer message 397 with the E-bit set through the request path. 399 3.1.3. Relay Agent 401 Implementations must conform to Section 2.8.1, 6.1.8 and 6.2.2 of 402 [RFC3588]. The topology shown in Figure 3 is also used for testing 403 relay agent functionality. Note that an overlap exists with the test 404 case described in Section 3.1.2 when testing relay agents and those 405 test cases should be used here as well. Verification for usage of 406 routing AVPs in Section 6.7 of [RFC3588] must be done when testing 407 agent functionality. Testing of proxy agents that keep vendor 408 specific state, such as proxy-info, proxy-state, proxy-host, is out 409 of scope of this document and can be done in parallel or independent 410 of the test cases enumerated here. 412 3.1.4. Redirection Agent 414 Implementation must conform to Section 6.1.7 of [RFC3588]. 415 Verification can be made by inspecting the redirect answer message 416 whether the result-code is set to DIAMETER_REDIRECT_INDICATION with 417 the E-bit enabled and redirect-hosts added. 418 o Positive test for redirection. Request messages generated from A1 419 should reach B2 via B1 using redirect from A2 and all links are up 420 except link0 and link2. A1 must be configured to forward request 421 message for realmB/B2 via A2. A2 must be configured to act as a 422 redirect agent and signal a redirect indication to A1 to use B1 423 instead. Verification of redirection can be done manually if 424 messages have reached B2 and re-direct indication was processed by 425 A1. 427 3.2. Optional 429 Implementations must conform to Section 5.6 of [RFC3588]. Test 430 topology uses Figure 1. This section describes optional test cases. 432 3.2.1. General Statemachine 434 Implementations must conform to Section 5.6.1 of [RFC3588]. The same 435 topology in Figure 1 can be used to perform the test scenarios listed 436 in this section. 437 o Negative test for non-CEA message received during CER/CEA 438 exchange. Silent discard and peer disconnection. Vendor B can 439 initiate a non Diameter server listening on a Diameter defined 440 port number to simulate unrecognizable messages from vendor B. Or 441 the AAA peer of vendor B is modified to generate a non-CEA message 442 once a transport connection setup has been initiated. Verify that 443 vendor A has closed the connection. 445 3.2.2. Dynamic Peer Discovery 447 Implementations must conform to Section 5.3 of [RFC3588]. 448 Implementations must be able to perform at least the following 449 behavior. 450 o Positive test for establishment of connection with unknown peer. 451 The topology for this test is Figure 1. Test case is dependent on 452 implementation accepting dynamic peer table updates. In such 453 case, lifetime of new peer entry should be check against lifetime 454 of connection. Intentionally configure vendor A to send an 455 origin-host that is not in B's peer table. Verification of result 456 can be done manually by inspecting the resulting peer table of B. 457 o Positive test after redirection (Section 3.1.4). The topology for 458 this test is Figure 3. Additional verification can be done if 459 Section 3.1.4 is successful. Redirect-host routes can be cached 460 by an implementation as a new route entry. Same scenarios as in 461 the redirect test case except subsequent request messages will be 462 forwarded to B1 by A1. Verify that only the initial message 463 results in a redirect process. 465 4. Diameter Base Protocol Application Support 467 4.1. Authentication and/or Authorization 469 Applications intending to use authentication and/or authorization 470 must conform to the statemachine specification in Section 8.1 of 471 [RFC3588]. Since these test cases are session level, any topology 472 can be used by a pair of vendors performing interoperability. The 473 minimum topology will be based on Figure 1. Note that majority of 474 these test are performed as part of other Diameter application test 475 cases. Therefore, implementations must be able to comply with these 476 common cases. 478 4.1.1. Stateful Session 480 Implementations must conform to Section 8.1 of [RFC3588]. 481 Implementations must be able to perform at least the following 482 behavior. 483 o Positive test for proper stateful session establishment. Verify 484 that auth-session-state with STATE_MAINTAINED is enforced in the 485 client session. Verify that auth-session-lifetime and auth- 486 session-grace-period are negotiated properly and enforced between 487 vendor implementations. Must conform to Section 8.4 of [RFC3588]. 488 o Positive test for proper stateful session re-auth. Verify server 489 initiated RAR/RAA exchange occurs on auth-lifetime and auth-grace 490 period expiration. Must conform to Section 8.3 of [RFC3588]. 492 o Positive test for proper stateful session disconnection. Verify 493 client initiated STR/STA exchange occurs for auth failure and 494 session timeout. Verify values of auth-lifetime and auth-grace 495 period against session-lifetime according to Section 8.9 of 496 [RFC3588]. Verify application id value carried by the STR/STA 497 message is that of the target application. 498 o Positive test for proper stateful session disconnection. Verify 499 server initiated ASR/ASA exchange occurs when server decides to 500 discontinue service. Implementations that allow for hard session 501 termination should be able to perform these tests. Must conform 502 to Section 8.5 of [RFC3588]. Verify application id value carried 503 by the STR/STA message is that of the target application. 504 o Positive test for proper stateful session disconnection using 505 origin-state-id. Verify a vendor implementation can at least 506 cleanup stateful sessions once it has received a value of origin- 507 state-id greater than a previously known value from the same 508 issuer. Verification can be done in the absence of an STR/STA 509 exchange. Must conform to Section 8.6 of [RFC3588]. 511 4.1.2. Stateless Session 513 Implementations must conform to Section 8.1 of [RFC3588]. 514 Implementations must be able to perform at least the following 515 behavior. 516 o Positive test for proper stateless session establishment. Verify 517 that auth-session-state negotiation between vendor implementation 518 with NO_STATE_MAINTAINED is enforced in the client session. 519 o Positive test for proper stateless session disconnection. Verify 520 that session-lifetime is enforced in the client session. 522 4.2. Accounting 524 Applications intending to use Diameter accounting may conform to 525 Section 8.2 and 9 of [RFC3588] if the particular application has not 526 already defined its own statemachine. Since these test cases are 527 also session level, any topology can be used by a pair of vendors 528 performing interoperability. The minimum topology will be based on 529 Figure 1. Note that majority of these test are performed as part of 530 other Diameter application test cases. Therefore, implementations 531 must be able to comply with these common cases. 533 4.2.1. Client Session 535 Implementations must conform to Section 8.2 of [RFC3588]. 536 Implementations must be able to perform at least the following 537 behavior. Verification of test results for these cases can be done 538 manually. 540 o Positive test for proper client session establishment. Verify 541 that sub-session id is supported and that the client can support 542 event record generation at the least. Verify that the client 543 should at least be able to support DELIVER_AND_GRANT. Test 544 entities must be able to configure their server implementation to 545 send this avp. Must conform to Section 9.4 and 9.8.7 of 546 [RFC3588]. 547 o Positive test for proper client session termination. Verify that 548 session termination causes transmission of stop record events if 549 any and that all records generated are accounted for. Validation 550 of accounting records can be Diameter application specific and is 551 left to the tester to confirm. 552 o Negative test for client session when server reports a failure. 553 Verify that client session can cope wistatemachine draft 554 submissionth failed accounting starts or server storage failure 555 and act accordingly based on Section 8.2 [RFC3588]. Behavior of 556 the client can be policy and implementation specific and is left 557 to the tester to confirm. Failed accounting starts and storage 558 failures can be simulated by mis-configuration of the server test 559 peer. 560 o Negative test for client session when connectivity fails. Verify 561 that client session can cope with connectivity failure and act 562 accordingly based on Section 9.4 [RFC3588]. The test can overlap 563 with Section 3.1.1.3 and Section 3.1.1.5. 565 4.2.2. Server Session 567 Implementations must conform to Section 8.2 and 9 of [RFC3588]. 568 Implementations must be able to perform at least the following 569 behavior. Verification of test results for these cases can be done 570 manually. Since server sessions must support record storage it is 571 left to the testers to validate storage (Section 9.5 [RFC3588]), 572 sequencing and co-relation (Section 9.6 [RFC3588]) of records. 573 o Positive test for proper server session establishment. Verify 574 that sub-session id is supported and that the server enforces 575 record generation on the client based on accounting-record-type. 576 Verify that supervision timer is enforced when using stateful 577 sessions. Must conform to Section 9.5 of [RFC3588]. 578 o Positive test for proper server session termination. Verify that 579 expiration of supervision timer in a stateful session terminates 580 both client and server session on any vendor implementation. 581 o Negative test for server session when local storage failure 582 occurs. Verify that server can notify client of its state and act 583 accordingly based on Section 8.2 of [RFC3588]. Validation is 584 policy and implementation specific and is left to the tester to 585 confirm. Storage failure can be simulated by mis-configuration on 586 the server test peer. This test is mostly a local validation but 587 it can be used in parallel with Section 4.2.1. 589 5. Security Considerations 591 This document defines test cases and therefore tests various aspects 592 of the Diameter base specification and various Diameter applications. 594 6. IANA Considerations 596 This document does not require actions by IANA. 598 7. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 604 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 606 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 607 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 609 Authors' Addresses 611 Victor Fajardo 612 Telcordia Technologies 613 1 Telcordia Drive #1S-222 614 Piscataway, NJ 08854 615 USA 617 Email: vfajardo@research.telcordia.com 619 Alan McNamee 620 Openet Telecom Inc 621 6 Beckett Way, Park West Business Park 622 Clondalkin, Dublin 12 623 Ireland 625 Phone: +353 1 620 4600 626 Email: alan.mcnamee@openet-telecom.com 627 Hannes Tschofenig 628 Nokia Siemens Networks 629 Linnoitustie 6 630 Espoo 02600 631 Finland 633 Phone: +358 (50) 4871445 634 Email: Hannes.Tschofenig@gmx.net 635 URI: http://www.tschofenig.priv.at 637 Julien Bournelle 638 France Telecom R&D 639 38-4O rue du general Leclerc 640 Issy-Les-Moulineaux 92794 641 France 643 Email: julien.bournelle@orange-ftgroup.com