idnits 2.17.00 (12 Aug 2021) /tmp/idnits4189/draft-fajardo-dime-base-test-suite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 725. 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 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 (April 28, 2007) is 5502 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 (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME Working Group V. Fajardo 3 Internet-Draft TARI 4 Expires: October 30, 2007 A. McNamee 5 Openet-Telecom 6 H. Tschofenig 7 NokiaSiemens 8 J. Bournelle 9 GET/INT 10 April 28, 2007 12 Diameter Base Protocol Interoperability Test Suite 13 draft-fajardo-dime-base-test-suite-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 30, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes a collection of test cases to be used for 47 Diameter base protocol interoperability testing. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Diameter Base Protocol Test Suite . . . . . . . . . . . . . . 5 54 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1.1. Connectivity and Peering . . . . . . . . . . . . . . . 5 56 3.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.1.3. Relay Agent . . . . . . . . . . . . . . . . . . . . . 11 58 3.1.4. Redirection Agent . . . . . . . . . . . . . . . . . . 12 59 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 3.2.1. General Statemachine . . . . . . . . . . . . . . . . . 12 61 3.2.2. Dynamic Peer Discovery . . . . . . . . . . . . . . . . 12 62 4. Diameter Base Protocol Application Support . . . . . . . . . . 14 63 4.1. Authentication and/or Authorization . . . . . . . . . . . 14 64 4.1.1. Stateful Session . . . . . . . . . . . . . . . . . . . 14 65 4.1.2. Stateless Session . . . . . . . . . . . . . . . . . . 15 66 4.2. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 15 67 4.2.1. Client Session . . . . . . . . . . . . . . . . . . . . 15 68 4.2.2. Server Session . . . . . . . . . . . . . . . . . . . . 16 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 71 7. Normative References . . . . . . . . . . . . . . . . . . . . . 19 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 73 Intellectual Property and Copyright Statements . . . . . . . . . . 21 75 1. Introduction 77 The document is meant to aid in the identifying the functional test 78 cases of a Diameter implementation. The Diameter interoperability 79 test suites are categorized by required and optional functionality. 80 The required functionality is the baseline capability that an 81 implementation must support to allow basic interoperability for that 82 category. Optional functionality covers features that not all 83 implementations support or may wish to test. This document also 84 covers test suites for common application support provided by the 85 diameter base protocol. 87 At its current state, this document provides only a collection of 88 test cases designed for interoperability. Test plans may be included 89 in future revisions of this work or maybe provided in some other 90 document. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 Within this document the terms defined in [RFC2119] refers to the 99 functionality that have to be provided by an implementation for the 100 usage within this interoperability test event. 102 3. Diameter Base Protocol Test Suite 104 All implementation must conform to [RFC3588]. 106 3.1. Required 108 3.1.1. Connectivity and Peering 110 Implementations must conform to Section 5.6 of [RFC3588]. Typical 111 test topology for statemachine test uses peer pairs as shown in 112 Figure 1. It is left to the testers if one-to-many or many-to-one 113 connections will be performed to test scalability and loading. The 114 test cases described below references Figure 1 below. 116 +--------+ +--------+ 117 |Vendor A|<---wired link---->|Vendor B| 118 +--------+ +--------+ 120 Figure 1: Peer Statemachine Test Topology 122 3.1.1.1. Capabilities Negotiation 124 Implementations must be able to perform at least the following 125 behavior described in Section 5.3 of [RFC3588]. 127 o Positive test for establishment of connection with test pairs 128 advertising support for common application ids (auth, accounting 129 or vendor). Vendor A initiates transport connection to B and 130 trigger the process. 132 o Positive test for establishment of connection with test pairs of 133 which one of them is advertising support for only relay app and no 134 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. 139 o Positive test for establishment of connection with test pairs 140 advertising support common transport security, specifically the 141 use of TLS and/or IPSec. It is left up to the participants to 142 generate appropriate keys and certificates specific for this test. 143 Vendor A initiates transport connection to B and trigger the 144 process and advertised proper Inband-Security support. 146 o Positive test for DWR/DWA exchange after connection is 147 established. Vendor A and B both exchange watchdogs as per 148 Section 3.4.1 of [RFC3539]. 150 o Negative test where DIAMETER_NO_COMMON_APPLICATION is returned by 151 a peer with no common application id (auth, accounting or vendor). 152 Intentionally configure vendor A not to advertise any 153 applications, different applications than B or vendor id's known 154 only to A. 156 o Negative test where DIAMETER_NO_COMMON_SECURITY is returned by a 157 peer with no common application id. Intentionally configure 158 vendor A to send Inband-Security-AVP with value 1 (TLS) that B 159 will not support. 161 o Negative test for unknown peers. Use of DIAMETER_UNKNOWN_PEER or 162 silent discard to disconnect unknown peers. Intentionally 163 configure vendor A to send an origin-host that is not in B's peer 164 table. 166 o Negative test case for TLS handshake failure. In the case where 167 the negotiated Inband-Security involves subsequent TLS 168 negotiation, participants can simulate a TLS handshake failure 169 (i.e. via invalid certificates, TLS/SSL version mis-match etc) 170 that must result in the peers being disconnected. 172 Verification of each test result can be done manually. 174 3.1.1.2. Election 176 This test case refers to Section 5.6.4 of [RFC3588]. Responders must 177 be able to resolve contention with initiator peers. 179 o Positive test for establishment of connection with responder 180 having higher identity than initiator. Vendor A initiates 181 connection followed by B doing the same a few milliseconds later. 182 Vendor A having a higher identity should close B's connection 183 attempt. 185 o Positive test for disconnection with initiator having lower 186 identity than the responder. Vendor A initiates a connection 187 followed by B doing the same a few milliseconds later. Vendor A 188 having a lower identity should close its initial connection 189 attempt. 191 o Negative test for disconnection when initiator and responder have 192 equal identity. Vendor A and B will advertise the equal identity. 193 Verify that both peers closed the connection. 195 Verification of test results can be done manually. 197 3.1.1.3. Disconnection 199 Implementations must conform to Section 5.6.4 of [RFC3588] and 200 Section 3.4.1 of [RFC3539]. Peers must be able to quickly determine 201 disconnection events. Verification of test results can be done 202 manually. 204 o Positive test for peer disconnection using DPR/DPA exchange. 205 Vendor A initiates shutdown while connected to B. Implementations 206 behavior may vary depending on disconnection cause such as an 207 eventual connection retry if a disconnection cause of REBOOTING is 208 received. 210 o Positive test for detecting disconnection via system level events 211 (i.e., transport resets, socket error, system link-down signals, 212 etc). Implementation must be able to initiate failover procedure. 213 Implementation should also attempt re-connection with lost peer. 214 Hard disconnection of vendor A and B's wired link can be done to 215 simulate this scenario. 217 o Positive test for detecting disconnection via watchdog timeout. 218 If there is no activity after a watchdog timer expires with 219 pending request then the peer becomes suspect and implementation 220 must be able to initiate failover procedure. [RFC3539] suggest a 221 minimum watchdog timeout at 6 sec. Vendor B can setup a transport 222 level filter to silently drop AAA traffic from B to simulate 223 unresponsiveness of B. 225 o Positive test for resetting connection after at least two(2) 226 watchdog has expired. If a connection is already suspect, the 227 peers must reset the connection. Vendor A or B can setup a 228 transport level filter to silently drop AAA traffic and simulate 229 unresponsiveness of both peers. 231 Verification of test results can be done manually. 233 3.1.1.4. Re-Connection Algorithms 235 Implementations must conform to Section 2.1 of [RFC3588]. Although a 236 vendor can implement other algorithms and policies than those 237 proposed in [RFC3588], a default reconnection scheme must be 238 implemented. 240 o Positive test for peer re-connection after disconnection has been 241 detected. The link between vendor A and B is temporarily 242 disconnected until such time that disconnection is detected by 243 both peers. The link can then be restored to test the re- 244 connection behavior of both peers. Verify that at least three(3) 245 watchdog exchanges occur before both peers are no longer suspect. 247 3.1.1.5. Failover and Failback 249 Implementations must conform to Section 5.4.5 of [RFC3588] and 250 Section 3.4.2 of [RFC3539]. Testing failover mechanism requires 251 alternate peer connections. A basic ring topology to test failover 252 and failback is shown in Figure 2 where vendor A has a primary route 253 to vendor C via vendor B and secondary route via vendor D. The same 254 symmetry is applied to all other vendors. As an example, vendor C 255 has a symmetric topology where D is its primary connection and B is 256 its secondary. This allows the same tests to be performed for all 257 vendors. For testing failover on vendor A and B, link0 can be 258 disconnected. For vendor C and D, link2 can be disconnected and so 259 on. 261 +---------+ 262 |Vendor B | 263 +---------+ 264 / \ 265 link0 link3 266 +---------+/ \+---------+ 267 |Vendor A | |Vendor C | 268 +---------+\ /+---------+ 269 link1 link2 270 \+---------+/ 271 |Vendor D | 272 +---------+ 274 Figure 2: Failover Test Topology 276 The enumerated test cases refers only to vendor A but can be applied 277 to any of the vendor implementations in Figure 2. Conditions for a 278 positive test requires that realm routes to C is present in A and 279 host routing is not used. Initial traffic should flow from A to C 280 via B (as the primary peer of A). 282 o Positive test for failover when link0 is disconnected. Vendor A 283 should have pending requests queued prior to disconnection. Upon 284 disconnection (see Section 3.1.1.3), verify that the pending 285 request with T-flag set has been forwarded to C via D. 287 o Positive test for failover by using device watchdog as a means of 288 triggering link0 disconnection. Vendor A should have pending 289 requests queued prior to disconnection. Upon disconnection (see 290 Section 3.1.1.3), verify that the pending request with T-flag set 291 has been forwarded to C via D. 293 o Positive test for failback when link0 is restored and re- 294 connection succeeds (See Section 3.1.1.4). Verify that new 295 request message is routed back to B. 297 o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answer 298 message from B to A when Destination-Host is set to C. This can be 299 simulated when link3 is disconnected and Vendor C is not reachable 300 from Vendor. Note that alternate path via Vendor D should not be 301 used. 303 o Negative test to detect duplicate messages on C. Vendor B can 304 disable watchdog processing but still allow request message 305 forwarding. This makes B a suspect peer from A and trigger 306 failover procedure. Forwarding of queue request will then be done 307 through D. However, the original request messages would have 308 reached C via B. 310 3.1.2. Routing 312 Implementation must conform to Section 6 of [RFC3588]. A basic 313 topology to test Diameter routing is shown in Figure 3 where vendor A 314 and vendor B can deploy two(2) Diameter peers to test host, realm and 315 answer message routing. Vendor A1 and A2 shares the same realm 316 (realmA). Vendor B1 and B2 share a different realm (realmB). Test 317 between both realms are symmetric although the description focuses 318 mostly to vendor A for editorial reasons. The topology is also 319 designed so that multi-hop forwarding, message loopback and agent 320 configuration can be tested. Note that some test cases in this 321 section require link disconnection overlap with the test cases 322 outline in Section 3.1.1.3. An implementation experiencing link 323 disconnection must update its peer and realm route table accordingly. 324 Verification for usage of proper routing AVPs in Section 6.7 of 325 [RFC3588] must be done when testing routing functionality. 327 +---------+ 328 |Vendor A2| (realmA) 329 +---------+ 330 / | \ 331 (realmA) link1 | link2 332 +---------+/ | \+---------+ 333 |Vendor A1| link0 |Vendor B2| (realmB) 334 +---------+\ | /+---------+ 335 link4 | link3 336 \+---------+/ 337 |Vendor B1| 338 +---------+ 339 (realmB) 341 Figure 3: Routing Test Topology 343 3.1.2.1. Peer Based Request Routing 345 Implementation must conform to Section 6.1.5 of [RFC3588]. In order 346 to perform the test cases the peer requesting the AAA routing must 347 have the destination-host and the destination-realm present in the 348 request message. 350 o Positive test for request forwarding from originator. Request 351 messages generated from A1 should reach B2 via B1 if destination- 352 host of the request is B2 and destination-realm is realmB and all 353 links are up. A1 must perform realm routing to reach B1 and B1 354 must perform forwarding to reach B2. Verification of routing can 355 be done manually if message has reached B2 via link4 and link3. 357 o Positive test for multi-hop request forwarding. Request messages 358 generated from A1 with destination-host B2 and destination-realm 359 realmB should reach B2 via A2 and B1 if all links are up except 360 for link4 and link2. A1 and A2 must perform realm routing while 361 B1 performs forwarding. A1 and A2 must be able to route the 362 request message to B1 even if it does not have B2 in its peer 363 table. Verification of routing can be done manually if message 364 has reached B2 via link1, link0 and link3. 366 o Negative test for request forwarding. If a request message 367 generated from A1 has a destination-host B2 and destination-realm 368 realmB with all links up except for link0, link2 and link4 then A2 369 must send an answer message to A1 with result-code 370 DIAMETER_UNABLE_TO_DELIVER. Verification can be done manually if 371 the answer message has reached A1 with E-bit set. 373 3.1.2.2. Realm Based Routing 375 Implementation must conform to Section 6.1 and Section 6.1.6 of 376 [RFC3588]. Test cases for realm-based request routing must have 377 destination-realm present but must not have destination-host present 378 in the request message. Note that there is some test overlap with 379 the test cases defined in Section 3.1.2.1. 381 o Positive test for request routing from originator. Request 382 messages generated from A1 should reach B2 via B1 if the 383 destination-realm is realmB and all links are up. A1 and B1 must 384 perform realm routing to reach B2. The request must have an id 385 (app, auth or vendor) that B1 must route and B2 must process 386 locally. Verification of routing can be done manually if message 387 has reached B2 via link4 and link3. 389 o Positive test for multi-hop request routing. Request messages 390 generated from A1 with destination-realm realmB should reach B2 391 via A2 and B1 if all links are up except for link4 and link2. A1, 392 A2 and B1 must perform realm routing. The request must have an id 393 (app, auth or vendor) that A1, A2 and B1 must route and B2 must 394 process locally. Verification of routing can be done manually if 395 message has reached B2 via link1, link0 and link3. 397 o Negative test for request routing. If a request message generated 398 from A1 has a destination-realm realmB with all links up except 399 for link0, link2 and link4 then A2 must send an answer message to 400 A1 with result-code DIAMETER_UNABLE_TO_DELIVER. Verification can 401 be done manually if the answer message has reached A1 with E-bit 402 set. 404 3.1.2.3. Answer Message Routing 406 Implementations must conform to Section 6.2 of [RFC3588]. Answer 407 routing can be verified using test cases in Section 3.1.2.1 and 408 Section 3.1.2.2. 410 3.1.2.4. Loop Detection 412 Implementation must conform to Section 6.1.3 of [RFC3588]. All 413 forwarders must verify that their local identity is not present in 414 the route-record of the request. If it is present, the forwarder 415 must send an answer with result-code DIAMETER_LOOP_DETECTED. If it 416 is not present, implementations must also insert route-records into 417 the request messages. 419 o Positive test for loop detection can be done if a request 420 originating from A1 has a destination-realm realmA and A1 is 421 configure to route request for realmA to A2, A2 will route request 422 for realmA to B1 and B1 will route request back to A1. Though A1 423 originated the request, it must be able to send an answer message 424 with the E-bit set through the request path. 426 3.1.3. Relay Agent 428 Implementations must conform to Section 2.8.1, 6.1.8 and 6.2.2 of 429 [RFC3588]. The topology shown in Figure 3 is also used for testing 430 relay agent functionality. Note that an overlap exists with the test 431 case described in Section 3.1.2 when testing relay agents and those 432 test cases should be used here as well. Verification for usage of 433 routing AVPs in Section 6.7 of [RFC3588] must be done when testing 434 agent functionality. Testing of proxy agents that keep vendor 435 specific state, such as proxy-info, proxy-state, proxy-host, is out 436 of scope of this document and can be done in parallel or independent 437 of the test cases enumerated here. 439 3.1.4. Redirection Agent 441 Implementation must conform to Section 6.1.7 of [RFC3588]. 442 Verification can be made by inspecting the redirect answer message 443 whether the result-code is set to DIAMETER_REDIRECT_INDICATION with 444 the E-bit enabled and redirect-hosts added. 446 o Positive test for redirection. Request messages generated from A1 447 should reach B2 via B1 using redirect from A2 and all links are up 448 except link0 and link2. A1 must be configured to forward request 449 message for realmB/B2 via A2. A2 must be configured to act as a 450 redirect agent and signal a redirect indication to A1 to use B1 451 instead. Verification of redirection can be done manually if 452 messages have reached B2 and re-direct indication was processed by 453 A1. 455 3.2. Optional 457 Implementations must conform to Section 5.6 of [RFC3588]. Test 458 topology uses Figure 1. This section describes optional test cases. 460 3.2.1. General Statemachine 462 Implementations must conform to Section 5.6.1 of [RFC3588]. The same 463 topology in Figure 1 can be used to perform the test scenarios listed 464 in this section. 466 o Negative test for non-CEA message received during CER/CEA 467 exchange. Silent discard and peer disconnection. Vendor B can 468 initiate a non Diameter server listening on a Diameter defined 469 port number to simulate unrecognizable messages from vendor B. Or 470 the AAA peer of vendor B is modified to generate a non-CEA message 471 once a transport connection setup has been initiated. Verify that 472 vendor A has closed the connection. 474 3.2.2. Dynamic Peer Discovery 476 Implementations must conform to Section 5.3 of [RFC3588]. 477 Implementations must be able to perform at least the following 478 behavior. 480 o Positive test for establishment of connection with unknown peer. 481 The topology for this test is Figure 1. Test case is dependent on 482 implementation accepting dynamic peer table updates. In such 483 case, lifetime of new peer entry should be check against lifetime 484 of connection. Intentionally configure vendor A to send an 485 origin-host that is not in B's peer table. Verification of result 486 can be done manually by inspecting the resulting peer table of B. 488 o Positive test after redirection (Section 3.1.4). The topology for 489 this test is Figure 3. Additional verification can be done if 490 Section 3.1.4 is successful. Redirect-host routes can be cached 491 by an implementation as a new route entry. Same scenarios as in 492 the redirect test case except subsequent request messages will be 493 forwarded to B1 by A1. Verify that only the initial message 494 results in a redirect process. 496 4. Diameter Base Protocol Application Support 498 4.1. Authentication and/or Authorization 500 Applications intending to use authentication and/or authorization 501 must conform to the statemachine specification in Section 8.1 of 502 [RFC3588]. Since these test cases are session level, any topology 503 can be used by a pair of vendors performing interoperability. The 504 minimum topology will be based on Figure 1. Note that majority of 505 these test are performed as part of other Diameter application test 506 cases. Therefore, implementations must be able to comply with these 507 common cases. 509 4.1.1. Stateful Session 511 Implementations must conform to Section 8.1 of [RFC3588]. 512 Implementations must be able to perform at least the following 513 behavior. 515 o Positive test for proper stateful session establishment. Verify 516 that auth-session-state with STATE_MAINTAINED is enforced in the 517 client session. Verify that auth-session-lifetime and auth- 518 session-grace-period are negotiated properly and enforced between 519 vendor implementations. Must conform to Section 8.4 of [RFC3588]. 521 o Positive test for proper stateful session re-auth. Verify server 522 initiated RAR/RAA exchange occurs on auth-lifetime and auth-grace 523 period expiration. Must conform to Section 8.3 of [RFC3588]. 525 o Positive test for proper stateful session disconnection. Verify 526 client initiated STR/STA exchange occurs for auth failure and 527 session timeout. Verify values of auth-lifetime and auth-grace 528 period against session-lifetime according to Section 8.9 of 529 [RFC3588]. Verify application id value carried by the STR/STA 530 message is that of the target application. 532 o Positive test for proper stateful session disconnection. Verify 533 server initiated ASR/ASA exchange occurs when server decides to 534 discontinue service. Implementations that allow for hard session 535 termination should be able to perform these tests. Must conform 536 to Section 8.5 of [RFC3588]. Verify application id value carried 537 by the STR/STA message is that of the target application. 539 o Positive test for proper stateful session disconnection using 540 origin-state-id. Verify a vendor implementation can at least 541 cleanup stateful sessions once it has received a value of origin- 542 state-id greater than a previously known value from the same 543 issuer. Verification can be done in the absence of an STR/STA 544 exchange. Must conform to Section 8.6 of [RFC3588]. 546 4.1.2. Stateless Session 548 Implementations must conform to Section 8.1 of [RFC3588]. 549 Implementations must be able to perform at least the following 550 behavior. 552 o Positive test for proper stateless session establishment. Verify 553 that auth-session-state negotiation between vendor implementation 554 with NO_STATE_MAINTAINED is enforced in the client session. 556 o Positive test for proper stateless session disconnection. Verify 557 that session-lifetime is enforced in the client session. 559 4.2. Accounting 561 Applications intending to use Diameter accounting may conform to 562 Section 8.2 and 9 of [RFC3588] if the particular application has not 563 already defined its own statemachine. Since these test cases are 564 also session level, any topology can be used by a pair of vendors 565 performing interoperability. The minimum topology will be based on 566 Figure 1. Note that majority of these test are performed as part of 567 other Diameter application test cases. Therefore, implementations 568 must be able to comply with these common cases. 570 4.2.1. Client Session 572 Implementations must conform to Section 8.2 of [RFC3588]. 573 Implementations must be able to perform at least the following 574 behavior. Verification of test results for these cases can be done 575 manually. 577 o Positive test for proper client session establishment. Verify 578 that sub-session id is supported and that the client can support 579 event record generation at the least. Verify that the client 580 should at least be able to support DELIVER_AND_GRANT. Test 581 entities must be able to configure their server implementation to 582 send this avp. Must conform to Section 9.4 and 9.8.7 of 583 [RFC3588]. 585 o Positive test for proper client session termination. Verify that 586 session termination causes transmission of stop record events if 587 any and that all records generated are accounted for. Validation 588 of accounting records can be Diameter application specific and is 589 left to the tester to confirm. 591 o Negative test for client session when server reports a failure. 592 Verify that client session can cope wistatemachine draft 593 submissionth failed accounting starts or server storage failure 594 and act accordingly based on Section 8.2 [RFC3588]. Behavior of 595 the client can be policy and implementation specific and is left 596 to the tester to confirm. Failed accounting starts and storage 597 failures can be simulated by mis-configuration of the server test 598 peer. 600 o Negative test for client session when connectivity fails. Verify 601 that client session can cope with connectivity failure and act 602 accordingly based on Section 9.4 [RFC3588]. The test can overlap 603 with Section 3.1.1.3 and Section 3.1.1.5. 605 4.2.2. Server Session 607 Implementations must conform to Section 8.2 and 9 of [RFC3588]. 608 Implementations must be able to perform at least the following 609 behavior. Verification of test results for these cases can be done 610 manually. Since server sessions must support record storage it is 611 left to the testers to validate storage (Section 9.5 [RFC3588]), 612 sequencing and co-relation (Section 9.6 [RFC3588]) of records. 614 o Positive test for proper server session establishment. Verify 615 that sub-session id is supported and that the server enforces 616 record generation on the client based on accounting-record-type. 617 Verify that supervision timer is enforced when using stateful 618 sessions. Must conform to Section 9.5 of [RFC3588]. 620 o Positive test for proper server session termination. Verify that 621 expiration of supervision timer in a stateful session terminates 622 both client and server session on any vendor implementation. 624 o Negative test for server session when local storage failure 625 occurs. Verify that server can notify client of its state and act 626 accordingly based on Section 8.2 of [RFC3588]. Validation is 627 policy and implementation specific and is left to the tester to 628 confirm. Storage failure can be simulated by mis-configuration on 629 the server test peer. This test is mostly a local validation but 630 it can be used in parallel with Section 4.2.1. 632 5. Security Considerations 634 This document defines test cases and therefore tests various aspects 635 of the Diameter base specification and various Diameter applications. 637 6. IANA Considerations 639 This document does not require actions by IANA. 641 7. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 647 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 649 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 650 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 652 Authors' Addresses 654 Victor Fajardo 655 Toshiba America Research, Inc. 656 1 Telcordia Drive 657 Piscataway, NJ 08854 658 USA 660 Phone: +1 732 699 5368 661 Email: vfajardo@tari.toshiba.com 663 Alan McNamee 664 Openet Telecom Inc 665 6 Beckett Way, Park West Business Park 666 Clondalkin, Dublin 12 667 Ireland 669 Phone: +353 1 620 4600 670 Email: alan.mcnamee@openet-telecom.com 672 Hannes Tschofenig 673 Nokia Siemens Networks 675 Phone: 676 Email: Hannes.Tschofenig@nsn.com 678 Julien Bournelle 679 Institut National des Telecommunications 680 9 rue Charles Fourier 681 Evry cedex, 91011 682 France 684 Phone: +33 1 60 76 44 79 685 Email: julien.bournelle@int-evry.fr 687 Full Copyright Statement 689 Copyright (C) The IETF Trust (2007). 691 This document is subject to the rights, licenses and restrictions 692 contained in BCP 78, and except as set forth therein, the authors 693 retain all their rights. 695 This document and the information contained herein are provided on an 696 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 697 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 698 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 699 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 700 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 701 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 703 Intellectual Property 705 The IETF takes no position regarding the validity or scope of any 706 Intellectual Property Rights or other rights that might be claimed to 707 pertain to the implementation or use of the technology described in 708 this document or the extent to which any license under such rights 709 might or might not be available; nor does it represent that it has 710 made any independent effort to identify any such rights. Information 711 on the procedures with respect to rights in RFC documents can be 712 found in BCP 78 and BCP 79. 714 Copies of IPR disclosures made to the IETF Secretariat and any 715 assurances of licenses to be made available, or the result of an 716 attempt made to obtain a general license or permission for the use of 717 such proprietary rights by implementers or users of this 718 specification can be obtained from the IETF on-line IPR repository at 719 http://www.ietf.org/ipr. 721 The IETF invites any interested party to bring to its attention any 722 copyrights, patents or patent applications, or other proprietary 723 rights that may cover technology that may be required to implement 724 this standard. Please address the information to the IETF at 725 ietf-ipr@ietf.org. 727 Acknowledgment 729 Funding for the RFC Editor function is provided by the IETF 730 Administrative Support Activity (IASA).