idnits 2.17.00 (12 Aug 2021) /tmp/idnits3561/draft-fajardo-dime-base-test-suite-01.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 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. 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 (July 1, 2007) is 5438 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: January 2, 2008 A. McNamee 5 Openet-Telecom 6 H. Tschofenig 7 Nokia Siemens Networks 8 J. Bournelle 9 France Telecom R&D 10 July 1, 2007 12 Diameter Base Protocol Interoperability Test Suite 13 draft-fajardo-dime-base-test-suite-01.txt 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 January 2, 2008. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Diameter Base Protocol Test Suite . . . . . . . . . . . . . . 3 54 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1.1. Connectivity and Peering . . . . . . . . . . . . . . . 3 56 3.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.3. Relay Agent . . . . . . . . . . . . . . . . . . . . . 9 58 3.1.4. Redirection Agent . . . . . . . . . . . . . . . . . . 10 59 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 3.2.1. General Statemachine . . . . . . . . . . . . . . . . . 10 61 3.2.2. Dynamic Peer Discovery . . . . . . . . . . . . . . . . 10 62 4. Diameter Base Protocol Application Support . . . . . . . . . . 11 63 4.1. Authentication and/or Authorization . . . . . . . . . . . 11 64 4.1.1. Stateful Session . . . . . . . . . . . . . . . . . . . 11 65 4.1.2. Stateless Session . . . . . . . . . . . . . . . . . . 12 66 4.2. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.1. Client Session . . . . . . . . . . . . . . . . . . . . 12 68 4.2.2. Server Session . . . . . . . . . . . . . . . . . . . . 13 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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] refer to the 99 functionality that has to be provided by an implementation for the 100 usage within this interoperability test document. 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]. 126 o Positive test for establishment of connection with test pairs 127 advertising support for common application ids (auth, accounting 128 or vendor). Vendor A initiates transport connection to B and 129 trigger the process. 130 o Positive test for establishment of connection with test pairs of 131 which one of them is advertising support for only relay app and no 132 other app is in common. 133 o Positive test for establishment of connection advertising the 134 relay app in auth app id, acct app id & VSA. 135 o Positive test for establishment of connection with test pairs 136 advertising support common transport security, specifically the 137 use of TLS and/or IPSec. It is left up to the participants to 138 generate appropriate keys and certificates specific for this test. 139 Vendor A initiates transport connection to B and trigger the 140 process and advertised proper Inband-Security support. 141 o Positive test for DWR/DWA exchange after connection is 142 established. Vendor A and B both exchange watchdogs as per 143 Section 3.4.1 of [RFC3539]. 144 o Negative test where DIAMETER_NO_COMMON_APPLICATION is returned by 145 a peer with no common application id (auth, accounting or vendor). 146 Intentionally configure vendor A not to advertise any 147 applications, different applications than B or vendor id's known 148 only to A. 149 o Negative test where DIAMETER_NO_COMMON_SECURITY is returned by a 150 peer with no common application id. Intentionally configure 151 vendor A to send Inband-Security-AVP with value 1 (TLS) that B 152 will not support. 153 o Negative test for unknown peers. Use of DIAMETER_UNKNOWN_PEER or 154 silent discard to disconnect unknown peers. Intentionally 155 configure vendor A to send an origin-host that is not in B's peer 156 table. 157 o Negative test case for TLS handshake failure. In the case where 158 the negotiated Inband-Security involves subsequent TLS 159 negotiation, participants can simulate a TLS handshake failure 160 (i.e. via invalid certificates, TLS/SSL version mis-match etc) 161 that must result in the peers being disconnected. 162 Verification of each test result can be done manually. 164 3.1.1.2. Election 166 This test case refers to Section 5.6.4 of [RFC3588]. Responders must 167 be able to resolve contention with initiator peers. 169 o Positive test for establishment of connection with responder 170 having higher identity than initiator. Vendor A initiates 171 connection followed by B doing the same a few milliseconds later. 172 Vendor A having a higher identity should close B's connection 173 attempt. 174 o Positive test for disconnection with initiator having lower 175 identity than the responder. Vendor A initiates a connection 176 followed by B doing the same a few milliseconds later. Vendor A 177 having a lower identity should close its initial connection 178 attempt. 179 o Negative test for disconnection when initiator and responder have 180 equal identity. Vendor A and B will advertise the equal identity. 181 Verify that both peers closed the connection. 182 Verification of test results can be done manually. 184 3.1.1.3. Disconnection 186 Implementations must conform to Section 5.6.4 of [RFC3588] and 187 Section 3.4.1 of [RFC3539]. Peers must be able to quickly determine 188 disconnection events. Verification of test results can be done 189 manually. 190 o Positive test for peer disconnection using DPR/DPA exchange. 191 Vendor A initiates shutdown while connected to B. Implementations 192 behavior may vary depending on disconnection cause such as an 193 eventual connection retry if a disconnection cause of REBOOTING is 194 received. 195 o Positive test for detecting disconnection via system level events 196 (i.e., transport resets, socket error, system link-down signals, 197 etc). Implementation must be able to initiate failover procedure. 198 Implementation should also attempt re-connection with lost peer. 199 Hard disconnection of vendor A and B's wired link can be done to 200 simulate this scenario. 201 o Positive test for detecting disconnection via watchdog timeout. 202 If there is no activity after a watchdog timer expires with 203 pending request then the peer becomes suspect and implementation 204 must be able to initiate failover procedure. [RFC3539] suggest a 205 minimum watchdog timeout at 6 sec. Vendor B can setup a transport 206 level filter to silently drop AAA traffic from B to simulate 207 unresponsiveness of B. 208 o Positive test for resetting connection after at least two(2) 209 watchdog has expired. If a connection is already suspect, the 210 peers must reset the connection. Vendor A or B can setup a 211 transport level filter to silently drop AAA traffic and simulate 212 unresponsiveness of both peers. 213 Verification of test results can be done manually. 215 3.1.1.4. Re-Connection Algorithms 217 Implementations must conform to Section 2.1 of [RFC3588]. Although a 218 vendor can implement other algorithms and policies than those 219 proposed in [RFC3588], a default reconnection scheme must be 220 implemented. 221 o Positive test for peer re-connection after disconnection has been 222 detected. The link between vendor A and B is temporarily 223 disconnected until such time that disconnection is detected by 224 both peers. The link can then be restored to test the re- 225 connection behavior of both peers. Verify that at least three(3) 226 watchdog exchanges occur before both peers are no longer suspect. 228 3.1.1.5. Failover and Failback 230 Implementations must conform to Section 5.4.5 of [RFC3588] and 231 Section 3.4.2 of [RFC3539]. Testing failover mechanism requires 232 alternate peer connections. A basic ring topology to test failover 233 and failback is shown in Figure 2 where vendor A has a primary route 234 to vendor C via vendor B and secondary route via vendor D. The same 235 symmetry is applied to all other vendors. As an example, vendor C 236 has a symmetric topology where D is its primary connection and B is 237 its secondary. This allows the same tests to be performed for all 238 vendors. For testing failover on vendor A and B, link0 can be 239 disconnected. For vendor C and D, link2 can be disconnected and so 240 on. 242 +---------+ 243 |Vendor B | 244 +---------+ 245 / \ 246 link0 link3 247 +---------+/ \+---------+ 248 |Vendor A | |Vendor C | 249 +---------+\ /+---------+ 250 link1 link2 251 \+---------+/ 252 |Vendor D | 253 +---------+ 255 Figure 2: Failover Test Topology 257 The enumerated test cases refers only to vendor A but can be applied 258 to any of the vendor implementations in Figure 2. Conditions for a 259 positive test requires that realm routes to C is present in A and 260 host routing is not used. Initial traffic should flow from A to C 261 via B (as the primary peer of A). 263 o Positive test for failover when link0 is disconnected. Vendor A 264 should have pending requests queued prior to disconnection. Upon 265 disconnection (see Section 3.1.1.3), verify that the pending 266 request with T-flag set has been forwarded to C via D. 267 o Positive test for failover by using device watchdog as a means of 268 triggering link0 disconnection. Vendor A should have pending 269 requests queued prior to disconnection. Upon disconnection (see 270 Section 3.1.1.3), verify that the pending request with T-flag set 271 has been forwarded to C via D. 272 o Positive test for failback when link0 is restored and re- 273 connection succeeds (See Section 3.1.1.4). Verify that new 274 request message is routed back to B. 275 o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answer 276 message from B to A when Destination-Host is set to C. This can be 277 simulated when link3 is disconnected and Vendor C is not reachable 278 from Vendor. Note that alternate path via Vendor D should not be 279 used. 280 o Negative test to detect duplicate messages on C. Vendor B can 281 disable watchdog processing but still allow request message 282 forwarding. This makes B a suspect peer from A and trigger 283 failover procedure. Forwarding of queue request will then be done 284 through D. However, the original request messages would have 285 reached C via B. 287 3.1.2. Routing 289 Implementation must conform to Section 6 of [RFC3588]. A basic 290 topology to test Diameter routing is shown in Figure 3 where vendor A 291 and vendor B can deploy two(2) Diameter peers to test host, realm and 292 answer message routing. Vendor A1 and A2 shares the same realm 293 (realmA). Vendor B1 and B2 share a different realm (realmB). Test 294 between both realms are symmetric although the description focuses 295 mostly to vendor A for editorial reasons. The topology is also 296 designed so that multi-hop forwarding, message loopback and agent 297 configuration can be tested. Note that some test cases in this 298 section require link disconnection overlap with the test cases 299 outline in Section 3.1.1.3. An implementation experiencing link 300 disconnection must update its peer and realm route table accordingly. 301 Verification for usage of proper routing AVPs in Section 6.7 of 302 [RFC3588] must be done when testing routing functionality. 304 +---------+ 305 |Vendor A2| (realmA) 306 +---------+ 307 / | \ 308 (realmA) link1 | link2 309 +---------+/ | \+---------+ 310 |Vendor A1| link0 |Vendor B2| (realmB) 311 +---------+\ | /+---------+ 312 link4 | link3 313 \+---------+/ 314 |Vendor B1| 315 +---------+ 316 (realmB) 318 Figure 3: Routing Test Topology 320 3.1.2.1. Peer Based Request Routing 322 Implementation must conform to Section 6.1.5 of [RFC3588]. In order 323 to perform the test cases the peer requesting the AAA routing must 324 have the destination-host and the destination-realm present in the 325 request message. 326 o Positive test for request forwarding from originator. Request 327 messages generated from A1 should reach B2 via B1 if destination- 328 host of the request is B2 and destination-realm is realmB and all 329 links are up. A1 must perform realm routing to reach B1 and B1 330 must perform forwarding to reach B2. Verification of routing can 331 be done manually if message has reached B2 via link4 and link3. 332 o Positive test for multi-hop request forwarding. Request messages 333 generated from A1 with destination-host B2 and destination-realm 334 realmB should reach B2 via A2 and B1 if all links are up except 335 for link4 and link2. A1 and A2 must perform realm routing while 336 B1 performs forwarding. A1 and A2 must be able to route the 337 request message to B1 even if it does not have B2 in its peer 338 table. Verification of routing can be done manually if message 339 has reached B2 via link1, link0 and link3. 340 o Negative test for request forwarding. If a request message 341 generated from A1 has a destination-host B2 and destination-realm 342 realmB with all links up except for link0, link2 and link4 then A2 343 must send an answer message to A1 with result-code 344 DIAMETER_UNABLE_TO_DELIVER. Verification can be done manually if 345 the answer message has reached A1 with E-bit set. 347 3.1.2.2. Realm Based Routing 349 Implementation must conform to Section 6.1 and Section 6.1.6 of 350 [RFC3588]. Test cases for realm-based request routing must have 351 destination-realm present but must not have destination-host present 352 in the request message. Note that there is some test overlap with 353 the test cases defined in Section 3.1.2.1. 354 o Positive test for request routing from originator. Request 355 messages generated from A1 should reach B2 via B1 if the 356 destination-realm is realmB and all links are up. A1 and B1 must 357 perform realm routing to reach B2. The request must have an id 358 (app, auth or vendor) that B1 must route and B2 must process 359 locally. Verification of routing can be done manually if message 360 has reached B2 via link4 and link3. 361 o Positive test for multi-hop request routing. Request messages 362 generated from A1 with destination-realm realmB should reach B2 363 via A2 and B1 if all links are up except for link4 and link2. A1, 364 A2 and B1 must perform realm routing. The request must have an id 365 (app, auth or vendor) that A1, A2 and B1 must route and B2 must 366 process locally. Verification of routing can be done manually if 367 message has reached B2 via link1, link0 and link3. 368 o Negative test for request routing. If a request message generated 369 from A1 has a destination-realm realmB with all links up except 370 for link0, link2 and link4 then A2 must send an answer message to 371 A1 with result-code DIAMETER_UNABLE_TO_DELIVER. Verification can 372 be done manually if the answer message has reached A1 with E-bit 373 set. 375 3.1.2.3. Answer Message Routing 377 Implementations must conform to Section 6.2 of [RFC3588]. Answer 378 routing can be verified using test cases in Section 3.1.2.1 and 379 Section 3.1.2.2. 381 3.1.2.4. Loop Detection 383 Implementation must conform to Section 6.1.3 of [RFC3588]. All 384 forwarders must verify that their local identity is not present in 385 the route-record of the request. If it is present, the forwarder 386 must send an answer with result-code DIAMETER_LOOP_DETECTED. If it 387 is not present, implementations must also insert route-records into 388 the request messages. 389 o Positive test for loop detection can be done if a request 390 originating from A1 has a destination-realm realmA and A1 is 391 configure to route request for realmA to A2, A2 will route request 392 for realmA to B1 and B1 will route request back to A1. Though A1 393 originated the request, it must be able to send an answer message 394 with the E-bit set through the request path. 396 3.1.3. Relay Agent 398 Implementations must conform to Section 2.8.1, 6.1.8 and 6.2.2 of 399 [RFC3588]. The topology shown in Figure 3 is also used for testing 400 relay agent functionality. Note that an overlap exists with the test 401 case described in Section 3.1.2 when testing relay agents and those 402 test cases should be used here as well. Verification for usage of 403 routing AVPs in Section 6.7 of [RFC3588] must be done when testing 404 agent functionality. Testing of proxy agents that keep vendor 405 specific state, such as proxy-info, proxy-state, proxy-host, is out 406 of scope of this document and can be done in parallel or independent 407 of the test cases enumerated here. 409 3.1.4. Redirection Agent 411 Implementation must conform to Section 6.1.7 of [RFC3588]. 412 Verification can be made by inspecting the redirect answer message 413 whether the result-code is set to DIAMETER_REDIRECT_INDICATION with 414 the E-bit enabled and redirect-hosts added. 415 o Positive test for redirection. Request messages generated from A1 416 should reach B2 via B1 using redirect from A2 and all links are up 417 except link0 and link2. A1 must be configured to forward request 418 message for realmB/B2 via A2. A2 must be configured to act as a 419 redirect agent and signal a redirect indication to A1 to use B1 420 instead. Verification of redirection can be done manually if 421 messages have reached B2 and re-direct indication was processed by 422 A1. 424 3.2. Optional 426 Implementations must conform to Section 5.6 of [RFC3588]. Test 427 topology uses Figure 1. This section describes optional test cases. 429 3.2.1. General Statemachine 431 Implementations must conform to Section 5.6.1 of [RFC3588]. The same 432 topology in Figure 1 can be used to perform the test scenarios listed 433 in this section. 434 o Negative test for non-CEA message received during CER/CEA 435 exchange. Silent discard and peer disconnection. Vendor B can 436 initiate a non Diameter server listening on a Diameter defined 437 port number to simulate unrecognizable messages from vendor B. Or 438 the AAA peer of vendor B is modified to generate a non-CEA message 439 once a transport connection setup has been initiated. Verify that 440 vendor A has closed the connection. 442 3.2.2. Dynamic Peer Discovery 444 Implementations must conform to Section 5.3 of [RFC3588]. 445 Implementations must be able to perform at least the following 446 behavior. 448 o Positive test for establishment of connection with unknown peer. 449 The topology for this test is Figure 1. Test case is dependent on 450 implementation accepting dynamic peer table updates. In such 451 case, lifetime of new peer entry should be check against lifetime 452 of connection. Intentionally configure vendor A to send an 453 origin-host that is not in B's peer table. Verification of result 454 can be done manually by inspecting the resulting peer table of B. 455 o Positive test after redirection (Section 3.1.4). The topology for 456 this test is Figure 3. Additional verification can be done if 457 Section 3.1.4 is successful. Redirect-host routes can be cached 458 by an implementation as a new route entry. Same scenarios as in 459 the redirect test case except subsequent request messages will be 460 forwarded to B1 by A1. Verify that only the initial message 461 results in a redirect process. 463 4. Diameter Base Protocol Application Support 465 4.1. Authentication and/or Authorization 467 Applications intending to use authentication and/or authorization 468 must conform to the statemachine specification in Section 8.1 of 469 [RFC3588]. Since these test cases are session level, any topology 470 can be used by a pair of vendors performing interoperability. The 471 minimum topology will be based on Figure 1. Note that majority of 472 these test are performed as part of other Diameter application test 473 cases. Therefore, implementations must be able to comply with these 474 common cases. 476 4.1.1. Stateful Session 478 Implementations must conform to Section 8.1 of [RFC3588]. 479 Implementations must be able to perform at least the following 480 behavior. 481 o Positive test for proper stateful session establishment. Verify 482 that auth-session-state with STATE_MAINTAINED is enforced in the 483 client session. Verify that auth-session-lifetime and auth- 484 session-grace-period are negotiated properly and enforced between 485 vendor implementations. Must conform to Section 8.4 of [RFC3588]. 486 o Positive test for proper stateful session re-auth. Verify server 487 initiated RAR/RAA exchange occurs on auth-lifetime and auth-grace 488 period expiration. Must conform to Section 8.3 of [RFC3588]. 489 o Positive test for proper stateful session disconnection. Verify 490 client initiated STR/STA exchange occurs for auth failure and 491 session timeout. Verify values of auth-lifetime and auth-grace 492 period against session-lifetime according to Section 8.9 of 493 [RFC3588]. Verify application id value carried by the STR/STA 494 message is that of the target application. 496 o Positive test for proper stateful session disconnection. Verify 497 server initiated ASR/ASA exchange occurs when server decides to 498 discontinue service. Implementations that allow for hard session 499 termination should be able to perform these tests. Must conform 500 to Section 8.5 of [RFC3588]. Verify application id value carried 501 by the STR/STA message is that of the target application. 502 o Positive test for proper stateful session disconnection using 503 origin-state-id. Verify a vendor implementation can at least 504 cleanup stateful sessions once it has received a value of origin- 505 state-id greater than a previously known value from the same 506 issuer. Verification can be done in the absence of an STR/STA 507 exchange. Must conform to Section 8.6 of [RFC3588]. 509 4.1.2. Stateless Session 511 Implementations must conform to Section 8.1 of [RFC3588]. 512 Implementations must be able to perform at least the following 513 behavior. 514 o Positive test for proper stateless session establishment. Verify 515 that auth-session-state negotiation between vendor implementation 516 with NO_STATE_MAINTAINED is enforced in the client session. 517 o Positive test for proper stateless session disconnection. Verify 518 that session-lifetime is enforced in the client session. 520 4.2. Accounting 522 Applications intending to use Diameter accounting may conform to 523 Section 8.2 and 9 of [RFC3588] if the particular application has not 524 already defined its own statemachine. Since these test cases are 525 also session level, any topology can be used by a pair of vendors 526 performing interoperability. The minimum topology will be based on 527 Figure 1. Note that majority of these test are performed as part of 528 other Diameter application test cases. Therefore, implementations 529 must be able to comply with these common cases. 531 4.2.1. Client Session 533 Implementations must conform to Section 8.2 of [RFC3588]. 534 Implementations must be able to perform at least the following 535 behavior. Verification of test results for these cases can be done 536 manually. 537 o Positive test for proper client session establishment. Verify 538 that sub-session id is supported and that the client can support 539 event record generation at the least. Verify that the client 540 should at least be able to support DELIVER_AND_GRANT. Test 541 entities must be able to configure their server implementation to 542 send this avp. Must conform to Section 9.4 and 9.8.7 of 543 [RFC3588]. 545 o Positive test for proper client session termination. Verify that 546 session termination causes transmission of stop record events if 547 any and that all records generated are accounted for. Validation 548 of accounting records can be Diameter application specific and is 549 left to the tester to confirm. 550 o Negative test for client session when server reports a failure. 551 Verify that client session can cope wistatemachine draft 552 submissionth failed accounting starts or server storage failure 553 and act accordingly based on Section 8.2 [RFC3588]. Behavior of 554 the client can be policy and implementation specific and is left 555 to the tester to confirm. Failed accounting starts and storage 556 failures can be simulated by mis-configuration of the server test 557 peer. 558 o Negative test for client session when connectivity fails. Verify 559 that client session can cope with connectivity failure and act 560 accordingly based on Section 9.4 [RFC3588]. The test can overlap 561 with Section 3.1.1.3 and Section 3.1.1.5. 563 4.2.2. Server Session 565 Implementations must conform to Section 8.2 and 9 of [RFC3588]. 566 Implementations must be able to perform at least the following 567 behavior. Verification of test results for these cases can be done 568 manually. Since server sessions must support record storage it is 569 left to the testers to validate storage (Section 9.5 [RFC3588]), 570 sequencing and co-relation (Section 9.6 [RFC3588]) of records. 571 o Positive test for proper server session establishment. Verify 572 that sub-session id is supported and that the server enforces 573 record generation on the client based on accounting-record-type. 574 Verify that supervision timer is enforced when using stateful 575 sessions. Must conform to Section 9.5 of [RFC3588]. 576 o Positive test for proper server session termination. Verify that 577 expiration of supervision timer in a stateful session terminates 578 both client and server session on any vendor implementation. 579 o Negative test for server session when local storage failure 580 occurs. Verify that server can notify client of its state and act 581 accordingly based on Section 8.2 of [RFC3588]. Validation is 582 policy and implementation specific and is left to the tester to 583 confirm. Storage failure can be simulated by mis-configuration on 584 the server test peer. This test is mostly a local validation but 585 it can be used in parallel with Section 4.2.1. 587 5. Security Considerations 589 This document defines test cases and therefore tests various aspects 590 of the Diameter base specification and various Diameter applications. 592 6. IANA Considerations 594 This document does not require actions by IANA. 596 7. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 602 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 604 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 605 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 607 Authors' Addresses 609 Victor Fajardo 610 Toshiba America Research, Inc. 611 1 Telcordia Drive 612 Piscataway, NJ 08854 613 USA 615 Phone: +1 732 699 5368 616 Email: vfajardo@tari.toshiba.com 618 Alan McNamee 619 Openet Telecom Inc 620 6 Beckett Way, Park West Business Park 621 Clondalkin, Dublin 12 622 Ireland 624 Phone: +353 1 620 4600 625 Email: alan.mcnamee@openet-telecom.com 626 Hannes Tschofenig 627 Nokia Siemens Networks 628 Otto-Hahn-Ring 6 629 Munich, Bavaria 81739 630 Germany 632 Phone: +49 89 636 40390 633 Email: Hannes.Tschofenig@nsn.com 634 URI: http://www.tschofenig.com 636 Julien Bournelle 637 France Telecom R&D 638 38-4O rue du general Leclerc 639 Issy-Les-Moulineaux 92794 640 France 642 Email: julien.bournelle@orange-ftgroup.com 644 Full Copyright Statement 646 Copyright (C) The IETF Trust (2007). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 This document and the information contained herein are provided on an 653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 655 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 656 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Intellectual Property 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Acknowledgment 686 Funding for the RFC Editor function is provided by the IETF 687 Administrative Support Activity (IASA).