idnits 2.17.00 (12 Aug 2021) /tmp/idnits18445/draft-fajardo-dime-misc-app-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 1674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1698. 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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (January 2007) is 5605 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 2716 (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 3012 (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: draft-ietf-aaa-diameter-sip-app has been published as RFC 4740 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group V. Fajardo 3 Internet-Draft TARI 4 Expires: July 5, 2007 A. McNamee 5 Openet-Telecom 6 H. Tschofenig 7 NokiaSiemens 8 J. Bournelle 9 GET/INT 10 January 2007 12 Diameter Applications Interoperability Test Suite 13 draft-fajardo-dime-misc-app-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 July 5, 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 applications interoperability testing. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Diameter SIP Test Suite . . . . . . . . . . . . . . . . . . . 6 54 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.1. Authentication . . . . . . . . . . . . . . . . . . . . 7 56 3.1.2. User Profile Update . . . . . . . . . . . . . . . . . 12 57 3.1.3. Proxy Service Authentication . . . . . . . . . . . . . 13 58 3.1.4. Location Service . . . . . . . . . . . . . . . . . . . 13 59 3.1.5. Soft Termination . . . . . . . . . . . . . . . . . . . 14 60 4. 3GPP Interface Test Suite . . . . . . . . . . . . . . . . . . 16 61 4.1. Diameter Cx . . . . . . . . . . . . . . . . . . . . . . . 16 62 4.1.1. Required . . . . . . . . . . . . . . . . . . . . . . . 17 63 4.2. Diameter Sh . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.2.1. Required . . . . . . . . . . . . . . . . . . . . . . . 19 65 4.3. Diameter Rf . . . . . . . . . . . . . . . . . . . . . . . 21 66 4.3.1. Required . . . . . . . . . . . . . . . . . . . . . . . 21 67 4.3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . 22 68 5. Diameter EAP Test Suite . . . . . . . . . . . . . . . . . . . 23 69 5.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 23 70 5.1.1. Non-Roaming case . . . . . . . . . . . . . . . . . . . 23 71 5.1.2. Roaming scenario . . . . . . . . . . . . . . . . . . . 24 72 5.2. Optional Authorization/Accounting Tests . . . . . . . . . 25 73 6. Diameter NASREQ Test Suite . . . . . . . . . . . . . . . . . . 26 74 6.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 27 75 6.1.1. Auth Session . . . . . . . . . . . . . . . . . . . . . 27 76 6.1.2. Diameter/RADIUS Gateway . . . . . . . . . . . . . . . 28 77 6.1.3. Multi-domain Scenario . . . . . . . . . . . . . . . . 28 78 6.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 29 79 6.2.1. Auth Session . . . . . . . . . . . . . . . . . . . . . 29 80 7. Diameter MIP Test Suite . . . . . . . . . . . . . . . . . . . 30 81 7.1. Generic MIP Test Scenarios . . . . . . . . . . . . . . . . 30 82 7.2. Required . . . . . . . . . . . . . . . . . . . . . . . . . 31 83 7.2.1. Co-located Registration . . . . . . . . . . . . . . . 31 84 7.2.2. Intra-Domain Registration . . . . . . . . . . . . . . 31 85 7.2.3. Inter-Domain Registration . . . . . . . . . . . . . . 32 86 7.2.4. Allocation of HA in Foreign Network . . . . . . . . . 34 87 7.3. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 35 88 7.3.1. Co-located Registration via Redirect Indication . . . 35 89 7.3.2. Inter-Domain Registration with Redirect . . . . . . . 36 90 7.3.3. Inter-Domain Registration with Proxy/Relay . . . . . . 37 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 93 10. Normative References . . . . . . . . . . . . . . . . . . . . . 42 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 95 Intellectual Property and Copyright Statements . . . . . . . . . . 45 97 1. Introduction 99 The document is a companion document to the Diameter Base Protocol 100 Interoperability Test Suite. The document is meant to aid in the 101 identifying the functional test cases of a Diameter implementation. 102 The Diameter interoperability test suites are categorized by 103 different applications or extensions. Each category is further 104 subdivided into required and optional functionality. The required 105 functionality is the baseline capability that an implementation must 106 support to allow basic interoperability dor that category. Optional 107 functionality covers features that not all implementations support or 108 may wish to test. The following is a list of Diameter applications 109 that are currently categorized in this document: 111 1. Diameter SIP 113 2. 3GPP Interfaces 115 3. Diameter EAP 117 4. Diameter NASREQ 119 5. Diameter MIP 121 Note that some of the test cases can overlap. For example, a NASREQ 122 test case would normally encompass base protocol routing. In such 123 cases, it is implied that multiple test scenario can be covered by 124 some test. 126 The Diameter Credit Control applications is not included in this 127 document but is published in a separate document (Diameter Credit 128 Control Interoperability Test Suite) to cover a wider set of test. 130 At its current state, this document provides only a collection of 131 test cases designed for interoperability. Test plans may be included 132 in future revisions of this work or maybe provided in some other 133 document. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 Within this document the terms defined in [RFC2119] refers to the 142 functionality that have to be provided by an implementation for the 143 usage within this interoperability test event. 145 3. Diameter SIP Test Suite 147 Implementations that deploy SIP [RFC3261] services and use Diameter 148 for authentication, authorization, signaling, profile distribution, 149 location services etc must conform to 150 [I-D.ietf-aaa-diameter-sip-app]. For the purpose of Diameter SIP, 151 each test nodes exercises only a specific set of functionality 152 depending on their role in the SIP architecture. Since this SIP 153 architecture is synonymous to Diameter Cx [TS29.228], the scenarios 154 enumerated in this section applies there as well. Therefore, there 155 can be a multitude of deployment scenarios. The test topology 156 follows the general architecture in Figure 1 of 157 [I-D.ietf-aaa-diameter-sip-app] in order to exercise the majority of 158 Diameter SIP features. For testing Diameter Cx, the mapping of the 159 test entities against this figure is described in Section 4.1. 160 Configuration of SIP user agents and SIP servers in all test cases 161 are implementation specific and it is left to the tester to verify 162 their correctness. 164 +--------+ 165 UAR/UAA +--->|Diameter|<----+ PPR/PPA 166 LIR/LIA | | server | | MAR/MAA 167 MAR/MAA | |Vendor B| | SAR/SAA 168 | +--------+ | RTR/RTA 169 | | 170 (realmB) | | (realmA) 171 v v 172 +------+ SIP +--------+ SIP +--------+ SIP +------+ 173 | SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP | 174 | UA1 | |server 1| |server 2| | UA2 | 175 +------+ |Vendor A| |Vendor D| +------+ 176 +--------+ +--------+ 177 Caller=user1@realmB ^ ^ Callee:user2@reamlA 178 | | 179 UAR/UAA | | 180 LIR/LIA | | MAR/MAA 181 | +--------+ | SAR/SAA 182 +--->|Diameter|<----+ 183 | SL | 184 |Vendor C| 185 +--------+ 187 Legend: 188 SIP UA's - SIP User Agents making/receiving calls 189 SIP server 1 - Vendor A acting as SIP proxy for reamlA 190 Diameter server - Vendor B acting as SIP auth server 191 Diameter SL - Vendor C acting as location server 192 SIP server 2 - Vendor D acting as SIP proxy for realmB 194 Figure 1: Diameter SIP Test Topology 196 3.1. Required 198 3.1.1. Authentication 200 Implementations must conform to Section 6.3 and 6.4 of 201 [I-D.ietf-aaa-diameter-sip-app]. All test entities should be present 202 to perform these test. The test scenarios check proper auth of 203 user1@realmB during SIP registration (SIP REGISTER) to SIP server 2. 204 Vendor A should be configured as proxy for UA1 and vendor D will be 205 the assigned SIP server for user1@realmB. Figure 2 and 3 of 206 [I-D.ietf-aaa-diameter-sip-app] can be used as a reference for these 207 test. All test scenario must follow the message flows described in 208 these figures. These test can be integrated with Section 3.1.4. For 209 simplicity, it is assumed that vendor A has knowledge of vendor B as 210 the Diameter server through static configuration or through the 211 location service. 213 o Positive test with Diameter server performing authentication. 214 Assuming proper configuration of all test entities, SIP REGISTER 215 request for user1@realmB should succeed with vendor D as the 216 allocated SIP server for the registration. The resulting message 217 flows should follow Figure 2 of [I-D.ietf-aaa-diameter-sip-app]. 218 For Diameter Cx, Section A.4.1 of [TS29.228] describes a similar 219 scenario. UAR/UAA exchanges must indicate to vendor A that D is 220 the preferred SIP server to handle user1@realmB registration. 221 Verify that DIAMETER_MULTI_ROUND_AUTH is followed by vendor A and 222 D and that vendor A generates SIP unauthorized response 223 accordingly. Verify that user1@realmB credentials and challenge 224 response is validated by vendor B in subsequent MAR/MAA exchanges. 226 o Positive test with SIP server performing authentication. Assuming 227 proper configuration of all test entities, SIP REGISTER request 228 for user1@realmB should succeed and the resulting message flows 229 should follow Figure 3 of [I-D.ietf-aaa-diameter-sip-app]. This 230 test scenarios is identical to the previous scenario except that 231 that nonces must be transferred from vendor B to D (Digest-HA1 232 avp). All verification procedure in the previous test applies. 234 o Positive test for server assignment. Assuming successful 235 authentication of user1@realmB, verify that vendor D is properly 236 allocated as the designated SIP server for this user. Verify that 237 this is a consequence of the previous positive tests and vendor B 238 is notified using SAR/SAA exchanges. Additional verification of 239 this scenario can be done with subsequent SIP request such as in 240 Section 3.1.3. 242 o Positive test for different settings of SIP-user-authorization- 243 type. Using the same scheme as previous positive test, verify 244 that registration can succeed with authorizations types 246 * REGISTRATION 248 * REGISTRATION_AND_CAPABILITIES 250 Additional configuration on vendor B maybe required to perform the 251 test. 253 o Positive test for registering an already registered user. Verify 254 that user1@realmB can properly re-register with vendor D and that 255 the re-registration triggers a SAR/SAA exchange between D and B to 256 update server assignments. Verify that the MAR/MAA exchanges are 257 skipped. The message flow should be as follows. 259 +--------+ +--------+ +--------+ 260 | SIP | |Diameter| | SIP | 261 |server 1| | server | |server 2| 262 |Vendor A| |Vendor B| |Vendor D| 263 +--------+ +--------+ +--------+ 264 | | | 265 1. SIP REGISTER | | | 266 -------------------->| 2. UAR | | 267 |------------------>| | 268 | 3. UAA | | 269 |<------------------| | 270 | 4. SIP REGISTER | 271 |-------------------------------------->| 272 | | 5. SAR | 273 | |<------------------| 274 | | 6. SAA | 275 | |------------------>| 276 | 7. SIP 200 (OK) | 277 8. SIP 200 (OK) |<--------------------------------------| 278 <--------------------| | | 279 | | | 281 Figure 2: Message Flow for Registration of Currently Registered 282 User 284 Note that the message flow is synonymous to Figure A.4.2.1 of 285 [TS29.228]. Therefore, the test scenario should apply to 286 Section 4.1 as well. 288 o Positive test for user initiated deregistration. Verify that 289 user1@realmB can properly de-register with vendor D and that the 290 de-registration triggers a SAR/SAA exchange between D and B to 291 remove server assignments. Must conform with Section 10.2.2 of 292 [RFC3261]. Soft state termination also apply as described in 293 Section 3.1.5. The message flow should be as follows. 295 +--------+ +--------+ +--------+ 296 | SIP | |Diameter| | SIP | 297 |server 1| | server | |server 2| 298 |Vendor A| |Vendor B| |Vendor D| 299 +--------+ +--------+ +--------+ 300 | | | 301 1. SIP REGISTER | | | 302 -------------------->| 2. UAR | | 303 |------------------>| | 304 | 3. UAA | | 305 |<------------------| | 306 | 4. SIP REGISTER | 307 |-------------------------------------->| 308 | | 5. SAR | 309 | |<------------------| 310 | | 6. SAA | 311 | |------------------>| 312 | 7. SIP 200 (OK) | 313 8. SIP 200 (OK) |<--------------------------------------| 314 <--------------------| | | 315 | | | 317 Figure 3: Message Flow for User Initiated De-registration 319 Note that the message flow is synonymous to Figure A.4.3.1 of 320 [TS29.228]. Therefore, the test scenario should apply to 321 Section 4.1 as well. 323 o Positive test for Diameter server initiated de-registration using 324 registration timeout. Verify that the server assignments are 325 remove from vendor D when vendor B decides to end the 326 registration. De-registration on vendor B can be simulated by 327 configuring a registration timeout for user1@realmB. Verify that 328 SAR/SAA exchanges are triggered by this event. The message flow 329 should be as follows. 331 +--------+ +--------+ +--------+ 332 | SIP | |Diameter| | SIP | 333 |server 1| | server | |server 2| 334 |Vendor A| |Vendor B| |Vendor D| 335 +--------+ +--------+ +--------+ 336 | | | 337 1. Timer Expires | 1. Timer Expires 338 | | | 339 | | 2. SAR | 340 | |<------------------| 341 | | 3. SAA | 342 | |------------------>| 343 | | | 345 Figure 4: Message Flow for Registration Timeouts 347 Note that the message flow is synonymous to Figure A.4.4.1 of 348 [TS29.228]. Therefore, the test scenario should apply to 349 Section 4.1 as well. 351 o Positive test for Diameter server initiated de-registration using 352 administrative means. Verify that the any soft states are removed 353 from vendor B. Administrative de-registration is implementation 354 specific and is left up to the tester to simulate. Note that soft 355 state termination also applies as described in Section 3.1.5. The 356 message flow should be as follows. 358 +--------+ +--------+ +--------+ 359 | SIP | |Diameter| | SIP | 360 |server 1| | server | |server 2| 361 |Vendor A| |Vendor B| |Vendor D| 362 +--------+ +--------+ +--------+ 363 | | | 364 | | 1. RTR | 365 | |------------------>| 366 | 2. De-REGISTER | | 367 |<--------------------------------------| 368 3. Inform | | | 369 <--------------------| 4. SIP 200 (0K) | | 370 5a. SIP 200 (0K) |-------------------------------------->| 371 -------------------->| | 5. RTA | 372 | |<------------------| 373 | | | 375 Figure 5: Message Flow for Administrative De-registration 377 Note that the message flow is synonymous to Figure A.4.4.2 of 378 [TS29.228]. Therefore, the test scenario should apply to 379 Section 4.1 as well. 381 o Negative test for auth when user-name avp is required by the 382 Diameter server. Verify that vendor A sends a SIP unauthorized 383 response back to UA1 if MAA is set to DIAMETER_USER_NAME_REQUIRED. 384 The result of the authentication/authorization may or may not be 385 successful in this context. Vendor B can be configured to require 386 a user-name in the UAR. This may not be applicable to all 387 implementations. 389 o Negative test for failed authorization. Verify the behavior of 390 vendor A and B when the criteria for the following errors are 391 meet. Verify that vendor A can terminate the call with UA1. Note 392 that for Diameter Cx, these codes may be present in the 393 experimental-result-code avp instead. 395 * DIAMETER_ERROR_USER_UNKNOWN. Simulation requires users 396 identity to be removed from vendor B. 398 * DIAMETER_ERROR_IDENTITIES_DONT_MATCH. Simulation may require 399 mis-configuration. 401 * DIAMETER_AUTHORIZATION_REJECTED. Simulate restrictions to user 402 access in the network. 404 * DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED. 406 3.1.2. User Profile Update 408 Implementations must conform to Section 6.8 of 409 [I-D.ietf-aaa-diameter-sip-app]. These test should be performed as a 410 consequence of Section 3.1.1. Updating of user profile in the 411 Diameter server is out of scope and it is left to the tester to 412 perform. The test scenario is also applicable to Section 6.6 of 413 [TS29.228] and synonymous to the message flow described in Figure 414 A.4.7.1 of the same document. 416 Positive test for updating user profile. Verify that a change in 417 the profile of user1@realmB can trigger a PPR/PPA exchange between 418 vendor B and D. 420 Negative test for failed authorization. Verify the behavior of 421 vendor B and D when the criteria for the following errors are 422 meet. 424 * DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some mis- 425 configuration. 427 * DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA. 429 * DIAMETER_UNABLE_TO_COMPLY. 431 3.1.3. Proxy Service Authentication 433 Implementations must conform to Section 6.5 and 6.6 of 434 [I-D.ietf-aaa-diameter-sip-app]. The test topology in Figure 1 can 435 be used to perform these test. Vendor A can be configured as the 436 outbound proxy for UA1 and vendor D for UA2. Note that the tests 437 performed on vendor A is symmetrical to vendor D. For simplicity, 438 only vendor A is noted here. These test can also be performed as a 439 consequence of positive tests in Section 3.1.1. The test scenarios 440 below use a call by user1@realmB to trigger authorization of SIP 441 INVITE request. 443 Positive test for proxy service authorization with nonces 444 generated by the Diameter server. Verify that at the least, 445 user1@realmB can make a call to user2@realmA with SIP requests 446 from vendor A authorized by vendor B. Verify that the SIP INVITEs 447 triggers a MAR/MAA exchange between vendor A and B and that user 448 credentials properly validated by vendor B. Note that vendor D 449 should route SIP request normally to simplify the test. The 450 message flow should follow Figure 4 of 451 [I-D.ietf-aaa-diameter-sip-app]. 453 Positive test for proxy service authorization with nonces 454 generated by the outbound SIP proxy. Verify that at the least, 455 user1@realmB can make a call to user2@realmA and that the user 456 credentials are validated by vendor B only after the challenge is 457 validated by vendor A. Verify that a valid challenge initiates a 458 MAR/MAA exchange between vendor A and B. Note that vendor D should 459 route SIP request normally to simplify the test. The message flow 460 should follow Figure 5 of [I-D.ietf-aaa-diameter-sip-app]. 462 Negative test for authorizing proxy service when user-name avp is 463 missing. Verify that vendor A sends a SIP unauthorized or SIP 464 authorization required messages back to UA1 if MAA is set to 465 DIAMETER_USER_NAME_REQUIRED. The result of the authorization may 466 or may not be successful in this context. Vendor B can be 467 configured to require a user-name in the UAR. This may not be 468 applicable to all implementations. 470 3.1.4. Location Service 472 Implementations must conform to Section 6.7 and 6.10 of 473 [I-D.ietf-aaa-diameter-sip-app] and Section 6.1.4 of [TS29.228]. All 474 test entities should be present to perform this test. The message 475 flow being tested is Figure 8. of [I-D.ietf-aaa-diameter-sip-app]. 476 This is also synonymous to Section A.4.5 of [TS29.228]. The test 477 topology in Figure 1 can be used to perform these test. The location 478 service test can be triggered by initiating a call to user2@realmA 479 from UA1. The presence of SIP and/or SIPS URI for user2@realmA in 480 vendor B can be done via SIP registration in Section 3.1.1 or some 481 other means. The test scenarios below assumes vendor D is the 482 allocated/assigned SIP server for user2@realmA. 484 o Positive test for location query using Diameter server. Vendor B 485 is pre-provision in vendor A as location server. for realmA. 486 Verify that a call (SIP INVITE) from UA1 to user2@realmA triggers 487 vendor A to send an LIR towards vendor B. Verify that vendor B 488 forwards the INVITE to vendor D upon receipt of LIA. 490 o Positive test for location query using Diameter SL. Vendor C is 491 pre-provisioned in vendor A as the location server. Verify that 492 the INVITE from UA1 to user2@realmA triggers vendor A to send an 493 LIR towards vendor C. Verify LIA redirection from vendor C causes 494 an LIR to be forwarded to vendor B. 496 o Negative test for failed authorization. Verify the behavior of 497 vendor B and D when the criteria for the following errors are 498 meet. 500 * DIAMETER_ERROR_USER_UNKNOWN. Simulation may require mis- 501 configuration. 503 * DIAMETER_UNABLE_TO_COMPLY. Simulation may require mis- 504 configuration. 506 * DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. 508 3.1.5. Soft Termination 510 Implementations must conform to Section 6.9 of 511 [I-D.ietf-aaa-diameter-sip-app] and 6.5.2.2 of [TS29.228]. These 512 test should be performed as a consequence of Section 3.1.1. In the 513 enumerated test scenarios, vendor A request removal of user bindings 514 in vendor B. This maybe a consequence of user1@reamlB logging off on 515 UA1 (Section 10.2.2 in [RFC3261]) or an expiration of usage timer in 516 vendor B. It is left to the implementation to configure such 517 scenario. 519 o Positive test for soft termination when session is stateless and 520 Diameter client initiates termination. Verify that at the least, 521 vendor D can send a SAR to vendor B when user1@realmB de- 522 registers. Note the appropriate result-codes are enumerated in 523 Section 6.9 of [I-D.ietf-aaa-diameter-sip-app]. This scenario is 524 synonymous to Figure 3. 526 o Positive test for soft termination when session is stateless and 527 Diameter server initiates termination. Verify that at the least, 528 vendor B can send an RTR to vendor D to AOR(s) for user1@realmB. 529 Testers can also simulate multiple AORs for the user and verify 530 that RTR can selectively remove specific AORs. It is left to the 531 testers to simulate a SIP-deregistration-reason from the Diameter 532 server. This scenario is synonymous to Figure 5. 534 o Positive test for soft termination when session is stateful and 535 Diameter client initiates termination. Verify that at the least, 536 vendor D can send an STR to vendor B when user1@realmB de- 537 registers. Verify application id value carried by the STR/STA 538 message is that of the target application. 540 o Positive test for soft termination when session is stateful and 541 Diameter server initiates termination. Verify that at the least, 542 vendor B can send an ASR to vendor B. Verify application id value 543 carried by the STR/STA message is that of the target application. 544 It is left to the testers to simulate session termination on the 545 Diameter server, i.e., session-timeout or registration timeout. 547 4. 3GPP Interface Test Suite 549 The test suite in this section only covers the following IMS 550 interfaces. Future revisions will attempt to cover the remaining 551 interfaces. 553 o Diameter Cx, [TS29.228] and [TS29.229]. 555 o Diameter Sh, [TS29.328] and [TS29.329]. 557 o Diameter Rf, [TS32.260]. 559 Because of the complexity in IMS deployment, a lot of assumptions 560 have been made in terms of the test topology. Since recreating an 561 IMS network is not realistic, only entities implementing Diameter 562 applications will be involved in these test cases. Peripheral 563 entities that instigate a test event should be simulated. 565 4.1. Diameter Cx 567 Implementations must conform to [TS29.228] and [TS29.229]. Since 568 Diameter Cx describes the same application as Diameter SIP, the test 569 topology and scenarios in Section 3 is applicable. For brevity, this 570 section will only provide addendums to the existing test suites in 571 Section 3 as it applies to Diameter Cx. Authentication schemes 572 present in the SIP tests may or may not be present for Cx testing. 573 The topology in Figure 1 will be used with the following mappings. 575 Diameter Cx Test Topology Vendor 576 Node Equivalent Assignments 577 ----------------+---------------------+----------------------- 579 I-CSCF SIP Server 1 Vendor A, I-CSCF 580 on Home Network 582 HSS Diameter Server Vendor B, HSS 583 on Home Network 585 S-CSCF SIP Server 2 Vendor D, S-CSCF 586 on Home Network 588 P-CSCF Optional Use UA1 to simulate 589 P-CSCF 591 AS Optional Implementation specific, 592 maybe simulated 594 Figure 6: SIP Test Topology Mapping 596 All test entities can share the same realm (Home Network). The SIP 597 proxy P-CSCF may or may not be present for testing the Cx interface. 598 If it is not available, tests for registration and de-registration 599 described in Section A.4.2 and A.4.3 of [TS29.228] can use UA1 to 600 simulate a P-CSCF. S-CSCF functions that rely on other entities such 601 as AS may also be simulated when service initiated test needs to be 602 performed. An AS maybe present to facilitate this though it is left 603 up to the implementation to provide an AS and verify its 604 configuration. 606 4.1.1. Required 608 The following are addendums to Section 3 for testing Diameter Cx. 610 o Positive test for de-registration initiated by S-CSCF. Verify 611 that a de-registration initiated by S-CSCF (vendor C) triggers the 612 removal of server assignments in vendor B. Verify SAR/SAA exchange 613 occurs. Message flow can be as follows. 615 +--------+ +--------+ 616 |Diameter| | SIP | 617 | server | |server 2| 618 |Vendor B| |Vendor D| 619 +--------+ +--------+ 620 | | 621 | 1. Simulated Service De-registration 622 2. De-register | | 623 <--------------------------------------| 624 | | 625 3. SIP 200 (OK) | | 626 ------------------------------------->| 627 | 4. SAR | 628 |<------------------| 629 | 5. SAA | 630 |------------------>| 631 | | 633 Figure 7: Message Flow for Service Initiated De-registration 635 o Positive test for session initiation to a non-registered user. 636 Verify that a call made by UA1 can initiate a server assignment by 637 vendor B for that call. Verify that the SIP INVITE also triggers 638 a location query (LIR/LIA exchange) with vendor B. Message flow 639 can be as follows. 641 +--------+ +--------+ +--------+ 642 | SIP | |Diameter| | SIP | 643 |server 1| | server | |server 2| 644 |Vendor A| |Vendor B| |Vendor D| 645 +--------+ +--------+ +--------+ 646 | | | 647 1. SIP INVITE | | | 648 -------------------->| 2. LIR | | 649 |------------------>| | 650 | 3. LIA | | 651 |<------------------| | 652 | | | 653 | 4. INVITE | | 654 |-------------------------------------->| 655 | | 5. SAR | 656 | |<------------------| 657 | | 6. SAA | 658 | |------------------>| 659 | | | 661 Figure 8: Message Flow for Session Initiation to a Non-registered 662 User 664 Normally, server selection is performed during this process. 665 Testers can verify if vendor A correctly determine vendor D as the 666 assigned SIP server. Additional service control functions may 667 also need to be performed by vendor D. Though those would be out 668 of scope of this document. 670 4.2. Diameter Sh 672 Implementations must conform to [TS29.328] and [TS29.329]. The test 673 topology for Diameter Sh is Figure 9. Because AS functionality is 674 implementation and service specific, it is left to the testers to 675 verify configuration of the provided service. UA registration with 676 AS services are also left up to the tester to verify. Some 677 interaction with the test topology for Section 4.1 maybe required in 678 certain test scenarios. 680 Home Network 682 +--------+ +--------+ 683 |Diameter| | AS | 684 IMS Network <---Cx--->| server |<--------->|Vendor E| 685 | |Vendor B| UDR/UDA | | 686 | +--------+ PUR/PUA +--------+ 687 | SNR/SNA | 688 | PNR/PNA | 689 | | 690 -------SIP to S-CSCF and UA1------- 692 Legend: 693 IMS Network - Test topology for Diameter SIP. 694 Network details are not shown 695 for brevity. 697 Diameter server - Vendor B acting HSS for Home Network. 698 Part of the IMS Network. 700 AS - Vendor E acting as AS 702 Figure 9: Diameter Sh Test Topology 704 The test topology shown above is an addendum to Figure 1. The AS 705 uses Diameter Sh with the HSS and SIP with S-CSCF and UA1 in the IMS 706 network. For Diameter Sh, the message flow being tested is defined 707 in Section B.1 of [TS29.328]. It is left to the testers to verify 708 that the AS is properly configured in the IMS network. 710 4.2.1. Required 712 The following are test scenarios to exercise Diameter Sh interface. 714 o Positive test for data handling. Implementations must conform to 715 Section 6.1.1 and 6.1.2 of [TS29.328]. Verify that vendor E is 716 capable of storing and retrieving service related data into vendor 717 B via PUR/PUA and UDR/UDA. If user1 in UA1 can register for 718 service to the vendor E, verify that vendor E is able to store 719 service related data into vendor B. If user1 can then register to 720 vendor D in the IMS network and trigger a third-party registration 721 to vendor E, verify that vendor E is able pull service related 722 data from vendor B. Verify correctness of the following identity- 723 set when reading data from vendor B. 725 * IMPLICIT_IDENTITIES 726 * REGISTERED_IDENTITIES 728 * ALL_IDENTITIES 730 o Positive test for subscription/notification. Implementations must 731 conform to Section 6.1.3 and 6.1.4 of [TS29.328]. Verify that 732 vendor E can successfully subscribe to notification in case of 733 data changes in vendor B. This test should be performed after the 734 previous positive test. Simulation of data changes in vendor B is 735 implementation specific. Verify that vendor B sends a PNR to E 736 when simulated changes occur. 738 o Negative test for data update. Verify behavior of both vendor B 739 and E when the criteria for following experimental result codes 740 are meet. 742 * DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED. Simulate update 743 restrictions for vendor E in vendor B. 745 * DIAMETER_ERROR_USER_UNKNOWN. 747 * DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions on 748 vendor B. Configuration of AS permission list maybe necessary. 750 * DIAMETER_PRIOR_UPDATE_IN_PROGRESS. 752 * DIAMETER_ERROR_TRANSPARENT_DATA_OUT_OF_SYNC. Simulation may 753 require some invalid configuration. 755 * DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some 756 invalid configuration. 758 o Negative test for data read and notification subscriptions. 759 Verify behavior of both vendor B and E when the criteria for 760 following experimental result codes are meet during data pull or 761 subscription. 763 * DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ. Simulate read 764 restrictions for vendor E in vendor B. 766 * DIAMETER_ERROR_USER_UNKNOWN. 768 * DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions on 769 vendor B. Configuration of AS permission list maybe necessary. 771 4.3. Diameter Rf 773 Implementations must conform to [TS32.260]. The test topology for 774 Diameter Rf is Figure 10. The test cases in this section do not 775 attempt to cover all accounting scenarios that are possible in an IMS 776 network. It only exercise accounting functions for test entities 777 listed in Figure 6. Because the test topology only describes a home 778 network, the Rf interface is limited to S-CSCF and I-CSCF accounting. 779 Record co-relation with a visited network is assumed not to be done. 780 The CDF entity should be reachable to the SIP servers in Figure 1 and 781 to the AS in Figure 9 if an AS is used. The test scenarios also 782 makes a lot of assumptions in testing non-Diameter related Rf 783 requirements such as the CDR formats, operator configuration of the 784 CDF, SIP based signaling or operator based decision on when to use 785 offline-charging etc. Since there can be a multitude of 786 configuration options, verification of actual billing schemes used 787 and its accuracy is left to the testers. 789 IMS Network 790 +----------+ 791 | | 792 <----ACR/ACA to SIP Server 1 ----->| CDF | 793 | Vendor F | 794 <----ACR/ACA to SIP Server 2 ----->| | 795 +----------+ 797 Legend: 798 IMS Network - Test topology for Diameter SIP and/or 799 Diameter Sh. Network details are not 800 shown for brevity. 802 CDF - Vendor F acting CDF for Home Network. 804 Figure 10: Diameter Rf Test Topology 806 4.3.1. Required 808 The following are test scenarios to exercise Diameter Rf interface. 810 o Positive test for SIP session establishment. Implementations must 811 conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or D 812 generates a START_RECORD on positive acknowledgment of SIP INVITE. 813 The SIP server involved depends on the UA location. The test 814 could be performed as part of Section 3.1.3. Note that only the 815 mandatory triggers are recommended to be tested. The remaining 816 triggers specified in Table 5.2.1.1 of [TS32.260] is left up to 817 the test pairs. 819 o Positive test for SIP session updates. Implementations must 820 conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or D 821 generates an INTERIM_RECORD on a SIP re-INVITE or UPDATE for an 822 existing SIP session. The test can be performed in sequence with 823 the previous positive test. 825 o Positive test for session-unrelated procedures. Implementations 826 must conform to Section 5.2.2.1.5 of [TS32.260]. Verify that 827 vendor A or D generates EVENT_RECORD on a SIP SUBSCRIBE signal. 828 The test can be performed in sequence with the previous positive 829 test. 831 o Positive test for SIP session termination. Implementations must 832 conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor D 833 generates STOP_RECORD on a SIP BYE signal. The test can be 834 performed in sequence with the previous positive test. 836 o Negative test for unsuccessful SIP session establishment. Verify 837 that if a SIP session establishment fails, that vendor A or D 838 generates an EVENT_RECORD. The SIP server involved depends on the 839 location of the UA initiating the session. 841 o Negative test for error cases. Verify that vendor A and/or D 842 follows Section 5.2.2.2 of [TS32.260]. The error cases in that 843 text are general and may overlap with error cases in the Diameter 844 Base Protocol Test Suite document. 846 4.3.2. Optional 848 The following are optional test scenarios to exercise Diameter Rf 849 interface. Note that details of the tests are skipped for brevity. 851 o Positive test for multi-party call. Assuming a new UA is 852 introduced in the home network and S-CSCF is provided by vendor D, 853 the call flow should follow Section 5.2.2.1.10 of [TS32.260]. 855 o Positive test for AS related procedures. If an AS is used, verify 856 that vendor E can generate EVENT_RECORDs for services rendered to 857 the UA. Such services are implementation specific. However, 858 examples of such service is described in Section 5.2.2.1.11 of 859 [TS32.260]. 861 5. Diameter EAP Test Suite 863 Access device and AAA servers that support Diameter EAP Application 864 must conform to [RFC4072]. A typical test for network access 865 authentication using Diameter EAP is shown in Figure 11. The User 866 has an EAP Client to be authenticated for network access. The test 867 cases only cover the NAS and Auth. Servers interoperability. To 868 perform these tests, one must choose an EAP method. It is 869 recommended to use an authentication method which derive keying 870 material to test key transport between Auth. Server and NAS. As an 871 example, EAP-TLS [RFC2716] can be used. 873 +--------+ +--------+ +---------------+ 874 | User |<--->| NAS |<--->| Auth Server 1 | 875 | | |Vendor A| | Vendor B | 876 +--------+ +--------+ +---------------+ 877 ^ 878 | 879 | 880 v 881 +---------------+ 882 | Auth Server 2 | 883 | Vendor C | 884 +---------------+ 886 Legend: 887 User 888 NAS - Vendor A Diam EAP client 889 Auth Server 1 - Vendor B Diam EAP server 890 Auth Server 2 - Vendor C Diam EAP server 892 Figure 11: Diameter EAP 894 5.1. Required 896 Implementation must conform to section 2 of [RFC4072]. NAS and Auth. 897 Servers advertises Diameter EAP support in their CER/CEA exchange. 899 5.1.1. Non-Roaming case 901 In this test, User, NAS and Auth. Server 1 belongs to the same 902 realm. 904 o Verify that all Diameter messages for a particular user contains 905 the same Session-Id AVP. 907 o Positive test for EAP initiation. Verify that the Auth. server 908 initiates an EAP session while receiving either a DER containing 909 an EAP-Payload AVP Empty (signifying an EAP-Start) or an EAP- 910 Payload AVP containing an EAP-Response of Type Identity (cf. 911 section 2.2 of [RFC4072]). 913 o Positive test for User-Name AVP. Verify that the User-Name AVP 914 sent in DER message by the NAS contains the value provided by the 915 User in the EAP exchange between User and NAS. 917 o Positive test for user registration. Verify that the Auth. server 918 1 can authenticate and authorize User given a proper configuration 919 (e.g. by using EAP-TLS method between the User and the Auth. 920 Server). Verify that the AAA message flows is correct (cf. 921 section 2.2 of [RFC4072]). 923 o Positive test for Key transport and configuration. If the EAP 924 authentication method derives keys, verify that the Auth. Server 925 correctly provide keying material to the NAS and that these keys 926 are correctly used between User and NAS. 928 o Positive test for session termination: User Disconnection. Verify 929 that if the User disconnects for the NAS, the NAS sends a STR 930 message to the Auth. Server. Verify that the Auth. Server 931 releases all state concerning this User. 933 o Positive test for session termination: Auth-lifetime expiration. 934 Verify that if the auth-lifetime expires, the NAS send a STR to 935 the Auth. server. Verify that the Auth. Server releases all 936 state concerning this User. 938 o Negative test for authentication. Verify that the Auth. Server 939 sends a DEA message containing a DIAMETER_AUTHENTICATION_REJECTED 940 result-code to the NAS if the User is not correctly authenticated. 942 5.1.2. Roaming scenario 944 In this scenario, User and Auth. Server 2 belongs to realmB while 945 NAS and Auth. Server 1 belongs to realm A. All tests described in 946 the Non-Roaming scenario must work. As we are in roaming scenario, 947 the following two tests should also be performed. 949 o Positive test for Diameter EAP Direct Routing. Verify that if NAS 950 is properly configured, it can directly send Diameter EAP messages 951 to Auth. Server 2. 953 o Positive test for Diameter EAP Proxy Routing. Verify that if NAS 954 and Auth. Servers are correctly configured, Diameter EAP messages 955 are exchanged between NAS and Auth. Server 2 through Auth. 956 Server 1. 958 5.2. Optional Authorization/Accounting Tests 960 o Positive test for Authorization AVPs. Verify that if some 961 authorizations are requested, the DEA containing the 962 DIAMETER_SUCCESS in the Result-Code AVP also contains appropriate 963 Authorization AVPs (cf. section 5 of [RFC4005]). 965 o Positive test for Accounting. Verify that NAS initiates 966 Accounting if authentication is successful and finishes it while 967 terminating the session. 969 o Positive test for re-authentication. Verify that the Auth. 970 Server can reauthenticate the User via the NAS. 972 o Positive test for Redirection. Verify that the Redirect Scenario 973 described in section 2.3.2 of [RFC4072] is supported. 975 6. Diameter NASREQ Test Suite 977 Access device that supports Diameter NASREQ extension must conform to 978 [RFC4005]. Typical test topology for single domain authentication 979 shown in Figure 12. The User entity typically employs PPP to access 980 the NAS and is normally implementation dependent. Since the test 981 cases covers only NAS and Auth Server interoperability, it is left to 982 the tester to verify correctness of the access method between User 983 and NAS and that this method is able to trigger creation of a NASREQ 984 client session in the NAS. 986 +--------+ +--------+ +-------------+ 987 | User |<--->| NAS |<--->| Auth Server | 988 | | |Vendor A| | Vendor B | 989 +--------+ +--------+ +-------------+ 991 Legend: 992 User - Simulated user 993 NAS - Vendor A Diam NASREQ client 994 Auth Sever - Vendor B Diam NASREQ server 996 Figure 12: Diameter NASREQ Test Topology 998 Another test topology can exist for testing Diameter/RADIUS gateways 999 as specified in Section 9 of [RFC4005]. This topology is available 1000 for vendors implementing a translation gateway. It should simulate a 1001 common deployment scenario where there is a prevalence of legacy 1002 RADIUS access devices ([RFC2865]). Since the test cases covers 1003 interoperability scenarios, validation must be done between NAS and 1004 Gateway. As with Figure 12, it is left to the tester to verify 1005 correctness of the access method between User and NAS. The test 1006 cases involving Figure 12 is also relevant to validating Gateway and 1007 Auth Server and should be used in this topology as well. 1009 +--------+ +--------+ +---------+ +-------------+ 1010 | User |<--->| NAS |<--->| Gateway |<--->| Auth Server | 1011 | | | | |Vendor A | | Vendor B | 1012 +--------+ +--------+ +---------+ +-------------+ 1014 Legend: 1015 User - Simulated user 1016 NAS - Simulated or vendor RADIUS client 1017 Gateway - Vendor A Diameter/RADIUS gateway 1018 Auth Sever - Vendor B Diam NASREQ server 1020 Figure 13: Translation Gateway Test Topology 1022 6.1. Required 1024 6.1.1. Auth Session 1026 Implementations must conform to Section 2 of [RFC4005]. Test 1027 topology Figure 12 can be used for these cases. These tests 1028 typically involves a myriad of configuration options. At the least 1029 an implementation must be able to grant access to a user with a 1030 reasonable level of security given the test cases below. The minimum 1031 test that should be performed is PPP CHAP and PPP EAP with MD5 1032 method. These tests are heavily dependent on other parameters that 1033 are implementation specific (username, password, medium type, 1034 calling-station-id etc). It is left to the tester to verify 1035 correctness of this process but it must conform to Section 2.1, 3.1 1036 and 3.2 of [RFC4005]. This includes conformance to the use of 1037 transport level security (TLS or IPsec) for signaling sensitive 1038 information, i.e., passwords etc. Verification of test cases can be 1039 done manually. 1041 o Positive test for proper Auth server session establishment with 1042 authorization and authentication. Verify that user can initiate 1043 an access-request via vendor A and that vendor B can respond when 1044 PPP negotiation begins. Vendor A and B can agree on the service- 1045 type. Verify that at the least B can support auth-request-type 1046 AUTHORIZE_AUTHENTICATE. 1048 o Positive test for proper NAS session establishment with 1049 authorization and authentication. Verify that user can initiate 1050 an access-request via vendor A and that vendor B can respond when 1051 PPP negotiation begins. Verify that A is able to support 1052 DIAMETER_MULTI_ROUND_AUTH result-code. 1054 o Positive test for proper NAS session establishment with PPP. 1055 Verify support for PPP CHAP/EAP in auth request/answer exchanges. 1056 Verify that call and session information are exchanged properly to 1057 conform to Section 4.1 of [RFC4005]. 1059 o Positive test for proper session termination. Verify that a NAS 1060 can initiate termination upon user disconnection. Verify that the 1061 auth server can abort a session. Must conform to Section 2.3 of 1062 [RFC4005]. 1064 o Positive test for installation of NAS-filter-rules. Filter rule 1065 implementation should at least carry the form IPFilterType as 1066 specified in Section 4.3 of [RFC3588]. Verify that the rules sent 1067 by the auth server is installed properly in the NAS for the 1068 specific user. Note that implementation extensions done to the 1069 NAS-filter-rule can affect interoperability between peers. If 1070 commonality or agreements among implementations regarding the 1071 definition of NAS-filter-rule can be found and it deviates from 1072 the specification, it should be duly noted and used as a basis for 1073 specifying future NAS-filter-rule extensions. 1075 o Negative test for session failure when service type is 1076 unsupported. Verify that the auth server can terminate the 1077 session with DIAMETER_INVALID_AVP_VALUE for an unsupported service 1078 type. 1080 6.1.2. Diameter/RADIUS Gateway 1082 Implementations must conform to Section 9 of [RFC4005]. Test 1083 topology Figure 13 can be used for these cases. Validation of these 1084 tests maybe localized to the Gateway (vendor A) but for the purpose 1085 of interoperability, end-to-end authentication and/or authorization 1086 must succeed between User and Auth Server (vendor B). 1088 o Positive test for forwarding RADIUS request as Diameter request. 1089 Verify that Section 9.1 of [RFC4005] is followed and that 1090 transaction states are maintained by the Gateway on behalf of the 1091 RADIUS client. 1093 o Positive test for forwarding RADIUS response from Diameter 1094 responses. Verify that Section 9.1 of [RFC4005] is followed and 1095 the session generated from the original RADIUS request is 1096 maintained. 1098 o Negative test for terminating a Diameter session upon auth 1099 failure. Conditions for termination is specified in Section 9.1 1100 of [RFC4005]. 1102 6.1.3. Multi-domain Scenario 1104 Test cases in this section is synonymous to Section 6.1.1 and all 1105 requirements in that section apply here as well. These scenarios, 1106 however, uses Figure 1 of Diameter Base Protocol Test Suite Document 1107 instead. Vendor A1 can acts as the NAS and B1 or B2 can act as the 1108 auth server. A2 or B1 can act as either a proxy/agent or redirect 1109 agent for A1. As with the routing test in Diameter Base Protocol 1110 Test Suite, these tests are symmetric to both vendors. 1112 o Positive test for multi-domain auth using proxy/relay agent. 1113 Verify that A2 acting as a proxy/relay can reliably forward auth- 1114 request and answers between A1 and B2. All test cases enumerated 1115 in Section 6.1.1 must be performed. Note that this test cases 1116 overlap with the relay testing done in Diameter Base Protocol Test 1117 Suite. It must conform to all requirements of those test. 1119 o Positive test for multi-domain auth using redirect agent. Verify 1120 that A2 or B1 acting as a redirect can successfully respond with 1121 redirect information to A1. All test cases enumerated in 1122 Section 6.1.1 must be performed. Note that this test cases 1123 overlap with the relay testing done in Diameter Base Protocol Test 1124 Suite. It must conform to all requirements of those test. 1126 6.2. Optional 1128 Implementations must conform to Section 2 of [RFC4005]. Test 1129 topology uses Figure 12. These are optional test that 1130 implementations can perform. 1132 6.2.1. Auth Session 1134 Implementations must conform to Section 2 of [RFC4005]. These test 1135 cases are in support of Section 6.1.1. 1137 o Positive test for proper NASREQ accounting. Verify that 1138 accounting session is initiated by vendor A if supported by the 1139 implementation. Implementations must conform to Section 8 of 1140 [RFC4005]. 1142 o Positive test for session re-authentication if supported. Must 1143 conform to Section 2.2 of [RFC4005]. Behavior maybe dependent on 1144 implementation and policy however auth-lifetime and auth-grace- 1145 period must be utilized. Must conform to 8.3 of [RFC3588]. 1147 7. Diameter MIP Test Suite 1149 Vendors that support Diameter Mobile IPv4 extension must conform to 1150 [RFC4004]. There are typically several topologies that is possible 1151 when deploying Diameter MIP. Those which are more likely to be 1152 deployed are included in this document. The test cases are also 1153 highly dependent on the topologies themselves hence each test case 1154 provides its own test topology. Configuration of the mobility agents 1155 (Mobile, HA and FA) for all test cases are implementation specific 1156 and it is left up to the tester to verify their correctness. Testers 1157 must also verify that the MIP implementation conforms to Section 4 of 1158 [RFC4004] as it relates to Diameter. Testers must also ensure that 1159 all positive test resulting in successful authentication and/or 1160 authorization must generate appropriate session keys and MSAs as 1161 needed. It should conform to [RFC3957] and [RFC3012] as it applies. 1162 This is implementation and policy dependent but can be as a 1163 consequence of positive test cases so it is worthwhile to verify. 1165 7.1. Generic MIP Test Scenarios 1167 The following are generic test scenarios that can be applied to any 1168 MIP test topology. It is enumerated here for simplicity since it is 1169 common to all topology. 1171 o Positive test for mobile registration. Verify that at the least, 1172 the HA can authenticate and authorize the Mobile given the proper 1173 configuration (MIP authorization extensions. Verify that the AAA 1174 message flows for the specific topology is followed. Verify that 1175 proper key distribution occurs in the process. If accounting is 1176 supported, verify that accounting-sub-session-id is used. 1178 o Positive test for session termination. Verify that the expiration 1179 of auth-lifetime causes an STR to be sent from the HA and that the 1180 message flows are valid. Verify that the AAAH releases all 1181 session state it keeps if any. The AAAH must conform to Section 1182 4.1.3 of [RFC4004]. 1184 o Positive test for re-authentication. Verify that the Mobile can 1185 successfully performs re-authentication if policy allows. Verify 1186 that the AMR sent by the FA or Mobile on re-auth and carries the 1187 original session-id, HA NAI and AAAH NAI as appropriate. 1188 Implementations must conform to [RFC3846]. 1190 o Negative test for failed registration or authentication. Verify 1191 that a failed authentication or registration causes an STR to be 1192 sent from the HA and that DIAMETER_AUTHENTICATION_REJECTED result- 1193 code is communicated back to the FA or Mobile in the AMA. Verify 1194 that the AAAH releases all session state it keeps if any. AAAH 1195 must conform to Section 4.1.3 of [RFC4004]. 1197 7.2. Required 1199 7.2.1. Co-located Registration 1201 Implementation must conform to Section 3.3 of [RFC4004]. Test 1202 topology for co-located mobile node deployment is shown below in 1203 Figure 14. Both HA and AAAH share the same realm which can be a home 1204 or foreign realm of the Mobile. Verifying the correctness of the 1205 Mobile to HA registration is out of scope for this document is left 1206 to the tester. However, it must conform to [RFC3344] and its 1207 successor document. Note also that there is a myriad of 1208 configuration options for this test case and it is left to the test 1209 pairs to agree on which and on how many configuration can and should 1210 be tested. 1212 +--------+ +--------+ +-------------+ 1213 | Mobile |<--->| HA |<--->| AAAH | 1214 | | |Vendor A| | Vendor B | 1215 +--------+ +--------+ +-------------+ 1217 Legend: 1218 Mobile - Mobile is IPv4 mobile node 1219 HA - Vendor A as a MIP Home Agent 1220 AAAH - Vendor B as a Home AAA server 1222 Figure 14: Test Topology for Co-located Mobile Node 1224 o All test scenarios in Section 7.1 must be performed. 1226 7.2.2. Intra-Domain Registration 1228 Implementation must conform to [RFC4004]. The basic test topology 1229 for single domain registration is shown below in Figure 15. All 1230 entities share the same realm with FA and HA presiding over different 1231 networks. The topology can be a combination of different vendor 1232 implementations. Testers must verify that the AAA message flows in 1233 Figure 15 are followed for the registration process. 1235 +---------+ 1236 | AAAH | 1237 |Vendor B | 1238 +---------+ 1239 AMR/AMA / \ HAR/HAA 1240 / \ 1241 +---------+ +---------+ 1242 | FA | | HA | 1243 |Vendor A | |Vendor C | 1244 +---------+ +---------+ 1245 ^ 1246 | Mobile IP 1247 v 1248 +---------+ 1249 | Mobile | 1250 +---------+ 1252 Legend: 1253 Mobile - Mobile is IPv4 mobile node 1254 FA - Vendor A as a MIP Foreign Agent 1255 AAAH - Vendor B as a Home AAA server 1256 HA - Vendor C as a MIP Home Agent 1258 Figure 15: Test Topology for Intra-Domain MIP 1260 o All test scenarios in Section 7.1 must be performed. If [RFC3846] 1261 is supported, MIP NAIs should be used to route the AMRs towards 1262 the AAAH. 1264 o Positive test for handover. Verify that if Mobile performs a 1265 handover to HA that de-registration occurs properly and subsequent 1266 AMR/AMA exchanges are appropriate. Verify also that the 1267 accounting session is maintained if any. 1269 o Negative test for failed allocation of home agent. Vendor B can 1270 be configured not to provide a home agent for the Mobile. Verify 1271 that DIAMETER_ERROR_HA_NOT_AVAILABLE is sent by vendor B to vendor 1272 A. Verify that the B releases all session state it keeps if any. 1273 Vendor B must conform to Section 4.1.3 of [RFC4004]. 1275 7.2.3. Inter-Domain Registration 1277 Implementation must conform to Section 3.1 of [RFC4004]. The basic 1278 test topology for inter-domain registration is shown below in 1279 Figure 16. A1 and A2 reside in realmA and B1 and B2 reside in 1280 realmB. The entities in the topology can be a combination of 1281 different vendor implementations. Verifying the correctness of the 1282 Mobile to FA discovery and registration is implementation specific 1283 and out of scope of this document. It is left to the tester to 1284 validate this process but it must conform to requirements [RFC3344] 1285 and its successor document. As with previous test cases in Diameter 1286 MIP, there is a myriad of configuration options for this test case 1287 and it is left to the test pairs to agree on which and on how many 1288 configuration can and should be tested. However, testers must verify 1289 that the AAA message flows in Figure 16 are followed for the 1290 registration process regardless of configuration. 1292 realmA (visited) realmB (home) 1293 +---------+ +---------+ 1294 | AAAF | AMR/AMA | AAAH | 1295 |Vendor A2|<----------->|Vendor B2| 1296 +---------+ +---------+ 1297 ^ ^ 1298 AMR/AMA | | HAR/HAA 1299 v v 1300 +---------+ +---------+ 1301 | FA | | HA | 1302 |Vendor A1| |Vendor B1| 1303 +---------+ +---------+ 1304 ^ 1305 | Mobile IP 1306 v 1307 +---------+ 1308 | Mobile | mn@realmB.com 1309 +---------+ 1311 Legend: 1312 Mobile - Mobile is IPv4 mobile node 1313 FA - Vendor A1 as a MIP Foreign Agent 1314 AAAF - Vendor A2 as a Foreign AAA server 1315 AAAH - Vendor B2 as a Home AAA server 1316 HA - Vendor B1 as a MIP Home Agent 1318 Figure 16: Test Topology for Inter-Domain MIP 1320 o All test scenarios in Section 7.1 must be performed. If [RFC3846] 1321 is supported, MIP NAIs should be used to route the AMRs towards 1322 the AAAH. 1324 o Positive test for handover. Verify that if Mobile performs a 1325 handover to B1 that de-registration occurs properly and subsequent 1326 AMR/AMA exchanges are appropriate. Verify also that the 1327 accounting session is maintained if any. 1329 o Negative test for failed allocation of home agent. B2 can be 1330 configured not to provide a home agent for the Mobile. Verify 1331 that DIAMETER_ERROR_HA_NOT_AVAILABLE sent by B2 is propagated to 1332 FA via the AMA. Verify that the B2 releases all session state it 1333 keeps if any. B2 must conform to Section 4.1.3 of [RFC4004]. 1335 7.2.4. Allocation of HA in Foreign Network 1337 Implementation must conform to Section 3.2 of [RFC4004]. The basic 1338 test topology for dynamically allocated HA is shown below in 1339 Figure 17. A1, A2 and A3 reside in realmA and B1 resides in realmB. 1340 The entities in the topology can be a combination of different vendor 1341 implementations. Policies in AAAF and AAAH must support dynamic 1342 allocation of an HA. Testers must verify that the AAA message flows 1343 in Figure 17 are followed for the registration and HA allocation 1344 process. 1346 realmA realmB 1347 +---------+ ------- AMR ------> +---------+ 1348 | AAAF | <----- HAR -------- | AAAH | 1349 +--->|Vendor A3| ------- HAA ------> |Vendor B1| 1350 | +---------+ <----- AMA -------- +---------+ 1351 | ^ | 1352 | | | 1353 HAR/HAA | AMR | | AMA 1354 v | v 1355 +---------+ +---------+ 1356 | HA | | FA | 1357 |Vendor A2| |Vendor A1| 1358 +---------+ +---------+ 1359 ^ 1360 +--------+ Mobile IP| 1361 | Mobile |<----------+ 1362 +--------+ 1364 Legend: 1365 Mobile - Mobile is IPv4 mobile node 1366 FA - Vendor A1 as a MIP Foreign Agent 1367 AAAF - Vendor A3 as a Foreign AAA server 1368 AAAH - Vendor B1 as a Home AAA server 1369 HA - Vendor A2 as a MIP Home Agent 1371 Figure 17: Test Topology for Allocation of HA in Foreign Network 1373 o All test scenarios in Section 7.1 must be performed. If [RFC3846] 1374 is supported, MIP NAIs should be used to route the AMRs towards 1375 the AAAH. For test scenarios resulting in the termination of the 1376 session, verify that the HA allocated in A2 is released if policy 1377 permits. 1379 o Negative test for failed allocation of home agent. B1 can be 1380 configured not to provide a home agent for the Mobile. Verify 1381 that DIAMETER_ERROR_HA_NOT_AVAILABLE sent by B1 is propagated to 1382 A1. Verify that the B1 releases all session state it keeps if 1383 any. B1 must conform to Section 4.1.3 of [RFC4004]. 1385 7.3. Optional 1387 Vendors that support Diameter Mobile IPv4 extension must conform to 1388 [RFC4004]. The following are optional test cases that can be 1389 performed for Diameter MIP. 1391 7.3.1. Co-located Registration via Redirect Indication 1393 An addendum to the topology shown in Figure 16 is shown in Figure 18. 1394 The redirect agent is introduced if additional transport security is 1395 required between HA and AAAH in the co-located scenario as described 1396 in Section 3.3 of [RFC4004]. Optional IPsec or TLS connectivity can 1397 be established between HA and AAAH. For simplicity Figure 18 differs 1398 from Figure 8 of [RFC4004] by not having an AAA proxy but relying on 1399 the redirect agent directly. 1401 +----------+ 1402 | Redirect | 1403 | Vendor B1| 1404 +----------+ 1405 | 1406 | 1407 +--------+ +--------+ +-------------+ 1408 | Mobile |<--->| HA |<--->| AAAH | 1409 | | |Vendor A| | Vendor B2 | 1410 +--------+ +--------+ +-------------+ 1412 Legend: 1413 Mobile - Mobile is IPv4 mobile node 1414 HA - Vendor A as a MIP Home Agent 1415 Redirect - Vendor B1 redirect agent 1416 AAAH - Vendor B2 as a Home AAA server 1418 Figure 18: Test Topology for Co-located Mobile Node with Redirect 1420 o Positive test for mobile registration. Verify that redirection 1421 occurs between HA and Redirect agent. Verify that a secure 1422 transport is established between HA and AAAH. Verify that at the 1423 least, vendor B2 can authenticate and authorized the Mobile given 1424 the proper configuration. 1426 o Verify that the all test cases in Section 7.2.1 is be applied in 1427 this test case as well. 1429 7.3.2. Inter-Domain Registration with Redirect 1431 An addendum to the topology shown in Figure 16 is shown in Figure 19. 1432 The redirect agent B3 is introduced if additional transport security 1433 is required and the use of an AAAF can be skipped. In this topology 1434 B3 shares the same realm a B1 and B2. Optional IPsec or TLS 1435 connectivity can be established between A1 and B2 as describe in 1436 Figure 3 of [RFC4004]. However, the secure connectivity can be 1437 omitted to simplify testing. 1439 +---------+ 1440 |Redirect | 1441 |Vendor B3| 1442 +---------+ 1443 / 1444 realmA (visited) / realmB (home) 1445 +---------+ +---------+ 1446 | AAAF | AMR/AMA | AAAH | 1447 |Vendor A2| -------|Vendor B2| 1448 +---------+ / +---------+ 1449 ^ / ^ 1450 AMR/AMA | / | HAR/HAA 1451 v / v 1452 +---------+ / +---------+ 1453 | FA | | HA | 1454 |Vendor A1| |Vendor B1| 1455 +---------+ +---------+ 1456 ^ 1457 | Mobile IP 1458 v 1459 +---------+ 1460 | Mobile | mn@realmB.com 1461 +---------+ 1463 Legend: 1464 Mobile - Mobile is IPv4 mobile node 1465 FA - Vendor A1 as a MIP Foreign Agent 1466 AAAF - Vendor A2 as a Foreign AAA server 1467 AAAH - Vendor B2 as a Home AAA server 1468 HA - Vendor B1 as a MIP Home Agent 1469 Redirect - Vendor B3 as a Redirect agent in reamlA 1471 Figure 19: Test Topology for Inter-Domain MIP with Redirect 1473 o Positive test for mobile registration. Verify that at the least, 1474 B1 acting as HA can authenticate and authorize the Mobile given 1475 the proper configuration. Verify that a secure transport is 1476 established between A1 and B2 if used. If accounting is 1477 supported, verify that accounting-sub-session-id is used. If 1478 [RFC3846] is supported, MIP NAIs should be used to route the 1479 message towards the HA. 1481 o Positive test for handover. Verify that if Mobile performs a 1482 handover to B1 that de-registration occurs properly and subsequent 1483 AMR/AMA exchanges are appropriate. Verify also that the 1484 accounting session is maintained if any. 1486 o Verify that the all test cases in Section 7.2.3 is be applied in 1487 this test case as well. 1489 7.3.3. Inter-Domain Registration with Proxy/Relay 1491 An addendum to the topology shown in Figure 16 is shown in Figure 20. 1492 The proxy/relay agent B3 exists between A2 and B2. In this topology 1493 B3 shares the same realm as B1 and B2. 1495 +------------+ 1496 |Proxy/Relay | 1497 |Vendor B3 | 1498 +------------+ 1499 / AMR/AMA \ 1500 realmA (visited) / \ realmB (home) 1501 +---------+ +---------+ 1502 | AAAF | | AAAH | 1503 |Vendor A2| |Vendor B2| 1504 +---------+ +---------+ 1505 ^ ^ 1506 AMR/AMA | | HAR/HAA 1507 v v 1508 +---------+ +---------+ 1509 | FA | | HA | 1510 |Vendor A1| |Vendor B1| 1511 +---------+ +---------+ 1512 ^ 1513 | Mobile IP 1514 v 1515 +---------+ 1516 | Mobile | mn@realmB.com 1517 +---------+ 1519 Legend: 1520 Mobile - Mobile is IPv4 mobile node 1521 FA - Vendor A1 as a MIP Foreign Agent 1522 AAAF - Vendor A2 as a Foreign AAA server 1523 AAAH - Vendor B2 as a Home AAA server 1524 HA - Vendor B1 as a MIP Home Agent 1525 Redirect - Vendor B3 as a Redirect agent in reamlA 1527 Figure 20: Test Topology for Inter-Domain MIP with Proxy/Relay 1529 o Positive test for mobile registration. Verify that at the least, 1530 B1 acting as HA can authenticate and authorize the Mobile given 1531 the proper configuration. Verify that B3 can reliably relay AMR/ 1532 AMA exchanges between A1 and A2. If accounting is supported, 1533 verify that accounting-sub-session-id is used. If [RFC3846] is 1534 supported, MIP NAIs should be used to route the message towards 1535 the HA. 1537 o Verify that the all test cases in Section 7.2.3 is be applied in 1538 this test case as well. 1540 o Positive test for handover. Verify that if Mobile performs a 1541 handover to B1 that de-registration occurs properly and subsequent 1542 AMR/AMA exchanges are appropriate. Verify also that the 1543 accounting session is maintained if any. 1545 8. Security Considerations 1547 This document defines test cases and therefore tests various aspects 1548 of the Diameter base specification and various Diameter applications. 1550 9. IANA Considerations 1552 This document does not require actions by IANA. 1554 10. Normative References 1556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1557 Requirement Levels", BCP 14, RFC 2119, March 1997. 1559 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1560 Protocol", RFC 2716, October 1999. 1562 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1563 "Remote Authentication Dial In User Service (RADIUS)", 1564 RFC 2865, June 2000. 1566 [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ 1567 Response Extensions", RFC 3012, November 2000. 1569 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1570 A., Peterson, J., Sparks, R., Handley, M., and E. 1571 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1572 June 2002. 1574 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1575 August 2002. 1577 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1578 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1580 [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for 1581 Carrying Network Access Identifiers", RFC 3846, June 2004. 1583 [RFC3957] Perkins, C. and P. Calhoun, "Authentication, 1584 Authorization, and Accounting (AAA) Registration Keys for 1585 Mobile IPv4", RFC 3957, March 2005. 1587 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 1588 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1589 August 2005. 1591 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1592 "Diameter Network Access Server Application", RFC 4005, 1593 August 2005. 1595 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1596 Authentication Protocol (EAP) Application", RFC 4072, 1597 August 2005. 1599 [I-D.ietf-aaa-diameter-sip-app] 1600 Garcia-Martin, M., "Diameter Session Initiation Protocol 1601 (SIP) Application", draft-ietf-aaa-diameter-sip-app-12 1602 (work in progress), April 2006. 1604 [TS29.228] 1605 3GPP, "IMS Cx and Dx interfaces : signalling flows and 1606 message contents", 3GPP TS 29.228 Version 7.0.0 2006. 1608 [TS29.229] 1609 3GPP, "IMS Cx and Dx interfaces based on the Diameter 1610 protocol; Protocol details", 3GPP TS 29.229 Version 1611 7.0.0 2006. 1613 [TS29.328] 1614 3GPP, "IMS Sh interface : signalling flows and message 1615 content", 3GPP TS 29.328 Version 6.8.0 2005. 1617 [TS29.329] 1618 3GPP, "IMS Sh interface based on the Diameter protocol; 1619 Protocol details", 3GPP TS 29.329 Version 6.6.0 2005. 1621 [TS32.260] 1622 3GPP, "IP Multimedia Subsystem (IMS) Charging", 3GPP TS 1623 32.260 Version 6.4.0 2005. 1625 Authors' Addresses 1627 Victor Fajardo 1628 Toshiba America Research, Inc. 1629 1 Telcordia Drive 1630 Piscataway, NJ 08854 1631 USA 1633 Phone: +1 732 699 5368 1634 Email: vfajardo@tari.toshiba.com 1636 Alan McNamee 1637 Openet Telecom Inc 1638 6 Beckett Way, Park West Business Park 1639 Clondalkin, Dublin 12 1640 Ireland 1642 Phone: +353 1 620 4600 1643 Email: alan.mcnamee@openet-telecom.com 1645 Hannes Tschofenig 1646 Nokia Siemens Networks 1648 Phone: 1649 Email: Hannes.Tschofenig@nsn.com 1651 Julien Bournelle 1652 Institut National des Telecommunications 1653 9 rue Charles Fourier 1654 Evry cedex, 91011 1655 France 1657 Phone: +33 1 60 76 44 79 1658 Email: julien.bournelle@int-evry.fr 1660 Full Copyright Statement 1662 Copyright (C) The IETF Trust (2007). 1664 This document is subject to the rights, licenses and restrictions 1665 contained in BCP 78, and except as set forth therein, the authors 1666 retain all their rights. 1668 This document and the information contained herein are provided on an 1669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1671 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1672 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1673 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1676 Intellectual Property 1678 The IETF takes no position regarding the validity or scope of any 1679 Intellectual Property Rights or other rights that might be claimed to 1680 pertain to the implementation or use of the technology described in 1681 this document or the extent to which any license under such rights 1682 might or might not be available; nor does it represent that it has 1683 made any independent effort to identify any such rights. Information 1684 on the procedures with respect to rights in RFC documents can be 1685 found in BCP 78 and BCP 79. 1687 Copies of IPR disclosures made to the IETF Secretariat and any 1688 assurances of licenses to be made available, or the result of an 1689 attempt made to obtain a general license or permission for the use of 1690 such proprietary rights by implementers or users of this 1691 specification can be obtained from the IETF on-line IPR repository at 1692 http://www.ietf.org/ipr. 1694 The IETF invites any interested party to bring to its attention any 1695 copyrights, patents or patent applications, or other proprietary 1696 rights that may cover technology that may be required to implement 1697 this standard. Please address the information to the IETF at 1698 ietf-ipr@ietf.org. 1700 Acknowledgment 1702 Funding for the RFC Editor function is provided by the IETF 1703 Administrative Support Activity (IASA).