idnits 2.17.1 draft-fajardo-dime-misc-app-test-suite-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5401 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) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME V. Fajardo 3 Internet-Draft Telcordia Technologies 4 Expires: January 14, 2010 A. McNamee 5 Openet-Telecom 6 H. Tschofenig 7 Nokia Siemens Networks 8 J. Bournelle 9 France Telecom R&D 10 July 13, 2009 12 Diameter Applications Interoperability Test Suite 13 draft-fajardo-dime-misc-app-test-suite-01.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes a collection of test cases to be used for 52 Diameter applications interoperability testing. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Diameter SIP Test Suite . . . . . . . . . . . . . . . . . . . 4 59 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1.1. Authentication . . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. User Profile Update . . . . . . . . . . . . . . . . . 10 62 3.1.3. Proxy Service Authentication . . . . . . . . . . . . . 10 63 3.1.4. Location Service . . . . . . . . . . . . . . . . . . . 11 64 3.1.5. Soft Termination . . . . . . . . . . . . . . . . . . . 12 65 4. 3GPP Interface Test Suite . . . . . . . . . . . . . . . . . . 13 66 4.1. Diameter Cx . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.1.1. Required . . . . . . . . . . . . . . . . . . . . . . . 14 68 4.2. Diameter Sh . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.2.1. Required . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.3. Diameter Rf . . . . . . . . . . . . . . . . . . . . . . . 17 71 4.3.1. Required . . . . . . . . . . . . . . . . . . . . . . . 18 72 4.3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . 19 73 5. Diameter EAP Test Suite . . . . . . . . . . . . . . . . . . . 19 74 5.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 5.1.1. Non-Roaming case . . . . . . . . . . . . . . . . . . . 20 76 5.1.2. Roaming scenario . . . . . . . . . . . . . . . . . . . 21 77 5.2. Optional Authorization/Accounting Tests . . . . . . . . . 21 78 6. Diameter NASREQ Test Suite . . . . . . . . . . . . . . . . . . 21 79 6.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 6.1.1. Auth Session . . . . . . . . . . . . . . . . . . . . . 23 81 6.1.2. Diameter/RADIUS Gateway . . . . . . . . . . . . . . . 24 82 6.1.3. Multi-domain Scenario . . . . . . . . . . . . . . . . 24 83 6.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 6.2.1. Auth Session . . . . . . . . . . . . . . . . . . . . . 25 85 7. Diameter MIP Test Suite . . . . . . . . . . . . . . . . . . . 25 86 7.1. Generic MIP Test Scenarios . . . . . . . . . . . . . . . . 25 87 7.2. Required . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 7.2.1. Co-located Registration . . . . . . . . . . . . . . . 26 89 7.2.2. Intra-Domain Registration . . . . . . . . . . . . . . 26 90 7.2.3. Inter-Domain Registration . . . . . . . . . . . . . . 27 91 7.2.4. Allocation of HA in Foreign Network . . . . . . . . . 29 92 7.3. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 7.3.1. Co-located Registration via Redirect Indication . . . 30 94 7.3.2. Inter-Domain Registration with Redirect . . . . . . . 31 95 7.3.3. Inter-Domain Registration with Proxy/Relay . . . . . . 32 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 98 10. Normative References . . . . . . . . . . . . . . . . . . . . . 33 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 101 1. Introduction 103 The document is a companion document to the Diameter Base Protocol 104 Interoperability Test Suite. The document is meant to aid in the 105 identifying the functional test cases of a Diameter implementation. 106 The Diameter interoperability test suites are categorized by 107 different applications or extensions. Each category is further 108 subdivided into required and optional functionality. The required 109 functionality is the baseline capability that an implementation must 110 support to allow basic interoperability dor that category. Optional 111 functionality covers features that not all implementations support or 112 may wish to test. The following is a list of Diameter applications 113 that are currently categorized in this document: 114 1. Diameter SIP 115 2. 3GPP Interfaces 116 3. Diameter EAP 117 4. Diameter NASREQ 118 5. Diameter MIP 120 Note that some of the test cases can overlap. For example, a NASREQ 121 test case would normally encompass base protocol routing. In such 122 cases, it is implied that multiple test scenario can be covered by 123 some test. 125 The Diameter Credit Control applications is not included in this 126 document but is published in a separate document (Diameter Credit 127 Control Interoperability Test Suite) to cover a wider set of test. 129 At its current state, this document provides only a collection of 130 test cases designed for interoperability. Test plans may be included 131 in future revisions of this work or maybe provided in some other 132 document. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 Within this document the terms defined in [RFC2119] refers to the 141 functionality that have to be provided by an implementation for the 142 usage within this interoperability test event. 144 3. Diameter SIP Test Suite 146 Implementations that deploy SIP [RFC3261] services and use Diameter 147 for authentication, authorization, signaling, profile distribution, 148 location services etc must conform to 149 [I-D.ietf-aaa-diameter-sip-app]. For the purpose of Diameter SIP, 150 each test nodes exercises only a specific set of functionality 151 depending on their role in the SIP architecture. Since this SIP 152 architecture is synonymous to Diameter Cx [TS29.228], the scenarios 153 enumerated in this section applies there as well. Therefore, there 154 can be a multitude of deployment scenarios. The test topology 155 follows the general architecture in Figure 1 of 156 [I-D.ietf-aaa-diameter-sip-app] in order to exercise the majority of 157 Diameter SIP features. For testing Diameter Cx, the mapping of the 158 test entities against this figure is described in Section 4.1. 159 Configuration of SIP user agents and SIP servers in all test cases 160 are implementation specific and it is left to the tester to verify 161 their correctness. 163 +--------+ 164 UAR/UAA +--->|Diameter|<----+ PPR/PPA 165 LIR/LIA | | server | | MAR/MAA 166 MAR/MAA | |Vendor B| | SAR/SAA 167 | +--------+ | RTR/RTA 168 | | 169 (realmB) | | (realmA) 170 v v 171 +------+ SIP +--------+ SIP +--------+ SIP +------+ 172 | SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP | 173 | UA1 | |server 1| |server 2| | UA2 | 174 +------+ |Vendor A| |Vendor D| +------+ 175 +--------+ +--------+ 176 Caller=user1@realmB ^ ^ Callee:user2@reamlA 177 | | 178 UAR/UAA | | 179 LIR/LIA | | MAR/MAA 180 | +--------+ | SAR/SAA 181 +--->|Diameter|<----+ 182 | SL | 183 |Vendor C| 184 +--------+ 186 Legend: 187 SIP UA's - SIP User Agents making/receiving calls 188 SIP server 1 - Vendor A acting as SIP proxy for reamlA 189 Diameter server - Vendor B acting as SIP auth server 190 Diameter SL - Vendor C acting as location server 191 SIP server 2 - Vendor D acting as SIP proxy for realmB 193 Figure 1: Diameter SIP Test Topology 195 3.1. Required 197 3.1.1. Authentication 199 Implementations must conform to Section 6.3 and 6.4 of 200 [I-D.ietf-aaa-diameter-sip-app]. All test entities should be present 201 to perform these test. The test scenarios check proper auth of 202 user1@realmB during SIP registration (SIP REGISTER) to SIP server 2. 203 Vendor A should be configured as proxy for UA1 and vendor D will be 204 the assigned SIP server for user1@realmB. Figure 2 and 3 of 205 [I-D.ietf-aaa-diameter-sip-app] can be used as a reference for these 206 test. All test scenario must follow the message flows described in 207 these figures. These test can be integrated with Section 3.1.4. For 208 simplicity, it is assumed that vendor A has knowledge of vendor B as 209 the Diameter server through static configuration or through the 210 location service. 211 o Positive test with Diameter server performing authentication. 212 Assuming proper configuration of all test entities, SIP REGISTER 213 request for user1@realmB should succeed with vendor D as the 214 allocated SIP server for the registration. The resulting message 215 flows should follow Figure 2 of [I-D.ietf-aaa-diameter-sip-app]. 216 For Diameter Cx, Section A.4.1 of [TS29.228] describes a similar 217 scenario. UAR/UAA exchanges must indicate to vendor A that D is 218 the preferred SIP server to handle user1@realmB registration. 219 Verify that DIAMETER_MULTI_ROUND_AUTH is followed by vendor A and 220 D and that vendor A generates SIP unauthorized response 221 accordingly. Verify that user1@realmB credentials and challenge 222 response is validated by vendor B in subsequent MAR/MAA exchanges. 223 o Positive test with SIP server performing authentication. Assuming 224 proper configuration of all test entities, SIP REGISTER request 225 for user1@realmB should succeed and the resulting message flows 226 should follow Figure 3 of [I-D.ietf-aaa-diameter-sip-app]. This 227 test scenarios is identical to the previous scenario except that 228 that nonces must be transferred from vendor B to D (Digest-HA1 229 avp). All verification procedure in the previous test applies. 230 o Positive test for server assignment. Assuming successful 231 authentication of user1@realmB, verify that vendor D is properly 232 allocated as the designated SIP server for this user. Verify that 233 this is a consequence of the previous positive tests and vendor B 234 is notified using SAR/SAA exchanges. Additional verification of 235 this scenario can be done with subsequent SIP request such as in 236 Section 3.1.3. 237 o Positive test for different settings of SIP-user-authorization- 238 type. Using the same scheme as previous positive test, verify 239 that registration can succeed with authorizations types 240 * REGISTRATION 241 * REGISTRATION_AND_CAPABILITIES 242 Additional configuration on vendor B maybe required to perform the 243 test. 244 o Positive test for registering an already registered user. Verify 245 that user1@realmB can properly re-register with vendor D and that 246 the re-registration triggers a SAR/SAA exchange between D and B to 247 update server assignments. Verify that the MAR/MAA exchanges are 248 skipped. The message flow should be as follows. 250 +--------+ +--------+ +--------+ 251 | SIP | |Diameter| | SIP | 252 |server 1| | server | |server 2| 253 |Vendor A| |Vendor B| |Vendor D| 254 +--------+ +--------+ +--------+ 255 | | | 256 1. SIP REGISTER | | | 257 -------------------->| 2. UAR | | 258 |------------------>| | 259 | 3. UAA | | 260 |<------------------| | 261 | 4. SIP REGISTER | 262 |-------------------------------------->| 263 | | 5. SAR | 264 | |<------------------| 265 | | 6. SAA | 266 | |------------------>| 267 | 7. SIP 200 (OK) | 268 8. SIP 200 (OK) |<--------------------------------------| 269 <--------------------| | | 270 | | | 272 Figure 2: Message Flow for Registration of Currently Registered 273 User 275 Note that the message flow is synonymous to Figure A.4.2.1 of 276 [TS29.228]. Therefore, the test scenario should apply to 277 Section 4.1 as well. 278 o Positive test for user initiated deregistration. Verify that 279 user1@realmB can properly de-register with vendor D and that the 280 de-registration triggers a SAR/SAA exchange between D and B to 281 remove server assignments. Must conform with Section 10.2.2 of 282 [RFC3261]. Soft state termination also apply as described in 283 Section 3.1.5. The message flow should be as follows. 285 +--------+ +--------+ +--------+ 286 | SIP | |Diameter| | SIP | 287 |server 1| | server | |server 2| 288 |Vendor A| |Vendor B| |Vendor D| 289 +--------+ +--------+ +--------+ 290 | | | 291 1. SIP REGISTER | | | 292 -------------------->| 2. UAR | | 293 |------------------>| | 294 | 3. UAA | | 295 |<------------------| | 296 | 4. SIP REGISTER | 297 |-------------------------------------->| 298 | | 5. SAR | 299 | |<------------------| 300 | | 6. SAA | 301 | |------------------>| 302 | 7. SIP 200 (OK) | 303 8. SIP 200 (OK) |<--------------------------------------| 304 <--------------------| | | 305 | | | 307 Figure 3: Message Flow for User Initiated De-registration 309 Note that the message flow is synonymous to Figure A.4.3.1 of 310 [TS29.228]. Therefore, the test scenario should apply to 311 Section 4.1 as well. 312 o Positive test for Diameter server initiated de-registration using 313 registration timeout. Verify that the server assignments are 314 remove from vendor D when vendor B decides to end the 315 registration. De-registration on vendor B can be simulated by 316 configuring a registration timeout for user1@realmB. Verify that 317 SAR/SAA exchanges are triggered by this event. The message flow 318 should be as follows. 320 +--------+ +--------+ +--------+ 321 | SIP | |Diameter| | SIP | 322 |server 1| | server | |server 2| 323 |Vendor A| |Vendor B| |Vendor D| 324 +--------+ +--------+ +--------+ 325 | | | 326 1. Timer Expires | 1. Timer Expires 327 | | | 328 | | 2. SAR | 329 | |<------------------| 330 | | 3. SAA | 331 | |------------------>| 332 | | | 334 Figure 4: Message Flow for Registration Timeouts 336 Note that the message flow is synonymous to Figure A.4.4.1 of 337 [TS29.228]. Therefore, the test scenario should apply to 338 Section 4.1 as well. 339 o Positive test for Diameter server initiated de-registration using 340 administrative means. Verify that the any soft states are removed 341 from vendor B. Administrative de-registration is implementation 342 specific and is left up to the tester to simulate. Note that soft 343 state termination also applies as described in Section 3.1.5. The 344 message flow should be as follows. 346 +--------+ +--------+ +--------+ 347 | SIP | |Diameter| | SIP | 348 |server 1| | server | |server 2| 349 |Vendor A| |Vendor B| |Vendor D| 350 +--------+ +--------+ +--------+ 351 | | | 352 | | 1. RTR | 353 | |------------------>| 354 | 2. De-REGISTER | | 355 |<--------------------------------------| 356 3. Inform | | | 357 <--------------------| 4. SIP 200 (0K) | | 358 5a. SIP 200 (0K) |-------------------------------------->| 359 -------------------->| | 5. RTA | 360 | |<------------------| 361 | | | 363 Figure 5: Message Flow for Administrative De-registration 365 Note that the message flow is synonymous to Figure A.4.4.2 of 366 [TS29.228]. Therefore, the test scenario should apply to 367 Section 4.1 as well. 369 o Negative test for auth when user-name avp is required by the 370 Diameter server. Verify that vendor A sends a SIP unauthorized 371 response back to UA1 if MAA is set to DIAMETER_USER_NAME_REQUIRED. 372 The result of the authentication/authorization may or may not be 373 successful in this context. Vendor B can be configured to require 374 a user-name in the UAR. This may not be applicable to all 375 implementations. 376 o Negative test for failed authorization. Verify the behavior of 377 vendor A and B when the criteria for the following errors are 378 meet. Verify that vendor A can terminate the call with UA1. Note 379 that for Diameter Cx, these codes may be present in the 380 experimental-result-code avp instead. 381 * DIAMETER_ERROR_USER_UNKNOWN. Simulation requires users 382 identity to be removed from vendor B. 383 * DIAMETER_ERROR_IDENTITIES_DONT_MATCH. Simulation may require 384 mis-configuration. 385 * DIAMETER_AUTHORIZATION_REJECTED. Simulate restrictions to user 386 access in the network. 387 * DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED. 389 3.1.2. User Profile Update 391 Implementations must conform to Section 6.8 of 392 [I-D.ietf-aaa-diameter-sip-app]. These test should be performed as a 393 consequence of Section 3.1.1. Updating of user profile in the 394 Diameter server is out of scope and it is left to the tester to 395 perform. The test scenario is also applicable to Section 6.6 of 396 [TS29.228] and synonymous to the message flow described in Figure 397 A.4.7.1 of the same document. 398 Positive test for updating user profile. Verify that a change in 399 the profile of user1@realmB can trigger a PPR/PPA exchange between 400 vendor B and D. 401 Negative test for failed authorization. Verify the behavior of 402 vendor B and D when the criteria for the following errors are 403 meet. 404 * DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some mis- 405 configuration. 406 * DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA. 407 * DIAMETER_UNABLE_TO_COMPLY. 409 3.1.3. Proxy Service Authentication 411 Implementations must conform to Section 6.5 and 6.6 of 412 [I-D.ietf-aaa-diameter-sip-app]. The test topology in Figure 1 can 413 be used to perform these test. Vendor A can be configured as the 414 outbound proxy for UA1 and vendor D for UA2. Note that the tests 415 performed on vendor A is symmetrical to vendor D. For simplicity, 416 only vendor A is noted here. These test can also be performed as a 417 consequence of positive tests in Section 3.1.1. The test scenarios 418 below use a call by user1@realmB to trigger authorization of SIP 419 INVITE request. 420 Positive test for proxy service authorization with nonces 421 generated by the Diameter server. Verify that at the least, 422 user1@realmB can make a call to user2@realmA with SIP requests 423 from vendor A authorized by vendor B. Verify that the SIP INVITEs 424 triggers a MAR/MAA exchange between vendor A and B and that user 425 credentials properly validated by vendor B. Note that vendor D 426 should route SIP request normally to simplify the test. The 427 message flow should follow Figure 4 of 428 [I-D.ietf-aaa-diameter-sip-app]. 429 Positive test for proxy service authorization with nonces 430 generated by the outbound SIP proxy. Verify that at the least, 431 user1@realmB can make a call to user2@realmA and that the user 432 credentials are validated by vendor B only after the challenge is 433 validated by vendor A. Verify that a valid challenge initiates a 434 MAR/MAA exchange between vendor A and B. Note that vendor D should 435 route SIP request normally to simplify the test. The message flow 436 should follow Figure 5 of [I-D.ietf-aaa-diameter-sip-app]. 437 Negative test for authorizing proxy service when user-name avp is 438 missing. Verify that vendor A sends a SIP unauthorized or SIP 439 authorization required messages back to UA1 if MAA is set to 440 DIAMETER_USER_NAME_REQUIRED. The result of the authorization may 441 or may not be successful in this context. Vendor B can be 442 configured to require a user-name in the UAR. This may not be 443 applicable to all implementations. 445 3.1.4. Location Service 447 Implementations must conform to Section 6.7 and 6.10 of 448 [I-D.ietf-aaa-diameter-sip-app] and Section 6.1.4 of [TS29.228]. All 449 test entities should be present to perform this test. The message 450 flow being tested is Figure 8. of [I-D.ietf-aaa-diameter-sip-app]. 451 This is also synonymous to Section A.4.5 of [TS29.228]. The test 452 topology in Figure 1 can be used to perform these test. The location 453 service test can be triggered by initiating a call to user2@realmA 454 from UA1. The presence of SIP and/or SIPS URI for user2@realmA in 455 vendor B can be done via SIP registration in Section 3.1.1 or some 456 other means. The test scenarios below assumes vendor D is the 457 allocated/assigned SIP server for user2@realmA. 458 o Positive test for location query using Diameter server. Vendor B 459 is pre-provision in vendor A as location server. for realmA. 460 Verify that a call (SIP INVITE) from UA1 to user2@realmA triggers 461 vendor A to send an LIR towards vendor B. Verify that vendor B 462 forwards the INVITE to vendor D upon receipt of LIA. 464 o Positive test for location query using Diameter SL. Vendor C is 465 pre-provisioned in vendor A as the location server. Verify that 466 the INVITE from UA1 to user2@realmA triggers vendor A to send an 467 LIR towards vendor C. Verify LIA redirection from vendor C causes 468 an LIR to be forwarded to vendor B. 469 o Negative test for failed authorization. Verify the behavior of 470 vendor B and D when the criteria for the following errors are 471 meet. 472 * DIAMETER_ERROR_USER_UNKNOWN. Simulation may require mis- 473 configuration. 474 * DIAMETER_UNABLE_TO_COMPLY. Simulation may require mis- 475 configuration. 476 * DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. 478 3.1.5. Soft Termination 480 Implementations must conform to Section 6.9 of 481 [I-D.ietf-aaa-diameter-sip-app] and 6.5.2.2 of [TS29.228]. These 482 test should be performed as a consequence of Section 3.1.1. In the 483 enumerated test scenarios, vendor A request removal of user bindings 484 in vendor B. This maybe a consequence of user1@reamlB logging off on 485 UA1 (Section 10.2.2 in [RFC3261]) or an expiration of usage timer in 486 vendor B. It is left to the implementation to configure such 487 scenario. 488 o Positive test for soft termination when session is stateless and 489 Diameter client initiates termination. Verify that at the least, 490 vendor D can send a SAR to vendor B when user1@realmB de- 491 registers. Note the appropriate result-codes are enumerated in 492 Section 6.9 of [I-D.ietf-aaa-diameter-sip-app]. This scenario is 493 synonymous to Figure 3. 494 o Positive test for soft termination when session is stateless and 495 Diameter server initiates termination. Verify that at the least, 496 vendor B can send an RTR to vendor D to AOR(s) for user1@realmB. 497 Testers can also simulate multiple AORs for the user and verify 498 that RTR can selectively remove specific AORs. It is left to the 499 testers to simulate a SIP-deregistration-reason from the Diameter 500 server. This scenario is synonymous to Figure 5. 501 o Positive test for soft termination when session is stateful and 502 Diameter client initiates termination. Verify that at the least, 503 vendor D can send an STR to vendor B when user1@realmB de- 504 registers. Verify application id value carried by the STR/STA 505 message is that of the target application. 506 o Positive test for soft termination when session is stateful and 507 Diameter server initiates termination. Verify that at the least, 508 vendor B can send an ASR to vendor B. Verify application id value 509 carried by the STR/STA message is that of the target application. 510 It is left to the testers to simulate session termination on the 511 Diameter server, i.e., session-timeout or registration timeout. 513 4. 3GPP Interface Test Suite 515 The test suite in this section only covers the following IMS 516 interfaces. Future revisions will attempt to cover the remaining 517 interfaces. 518 o Diameter Cx, [TS29.228] and [TS29.229]. 519 o Diameter Sh, [TS29.328] and [TS29.329]. 520 o Diameter Rf, [TS32.260]. 521 Because of the complexity in IMS deployment, a lot of assumptions 522 have been made in terms of the test topology. Since recreating an 523 IMS network is not realistic, only entities implementing Diameter 524 applications will be involved in these test cases. Peripheral 525 entities that instigate a test event should be simulated. 527 4.1. Diameter Cx 529 Implementations must conform to [TS29.228] and [TS29.229]. Since 530 Diameter Cx describes the same application as Diameter SIP, the test 531 topology and scenarios in Section 3 is applicable. For brevity, this 532 section will only provide addendums to the existing test suites in 533 Section 3 as it applies to Diameter Cx. Authentication schemes 534 present in the SIP tests may or may not be present for Cx testing. 535 The topology in Figure 1 will be used with the following mappings. 537 Diameter Cx Test Topology Vendor 538 Node Equivalent Assignments 539 ----------------+---------------------+----------------------- 541 I-CSCF SIP Server 1 Vendor A, I-CSCF 542 on Home Network 544 HSS Diameter Server Vendor B, HSS 545 on Home Network 547 S-CSCF SIP Server 2 Vendor D, S-CSCF 548 on Home Network 550 P-CSCF Optional Use UA1 to simulate 551 P-CSCF 553 AS Optional Implementation specific, 554 maybe simulated 556 Figure 6: SIP Test Topology Mapping 558 All test entities can share the same realm (Home Network). The SIP 559 proxy P-CSCF may or may not be present for testing the Cx interface. 560 If it is not available, tests for registration and de-registration 561 described in Section A.4.2 and A.4.3 of [TS29.228] can use UA1 to 562 simulate a P-CSCF. S-CSCF functions that rely on other entities such 563 as AS may also be simulated when service initiated test needs to be 564 performed. An AS maybe present to facilitate this though it is left 565 up to the implementation to provide an AS and verify its 566 configuration. 568 4.1.1. Required 570 The following are addendums to Section 3 for testing Diameter Cx. 571 o Positive test for de-registration initiated by S-CSCF. Verify 572 that a de-registration initiated by S-CSCF (vendor C) triggers the 573 removal of server assignments in vendor B. Verify SAR/SAA exchange 574 occurs. Message flow can be as follows. 576 +--------+ +--------+ 577 |Diameter| | SIP | 578 | server | |server 2| 579 |Vendor B| |Vendor D| 580 +--------+ +--------+ 581 | | 582 | 1. Simulated Service De-registration 583 2. De-register | | 584 <--------------------------------------| 585 | | 586 3. SIP 200 (OK) | | 587 ------------------------------------->| 588 | 4. SAR | 589 |<------------------| 590 | 5. SAA | 591 |------------------>| 592 | | 594 Figure 7: Message Flow for Service Initiated De-registration 596 o Positive test for session initiation to a non-registered user. 597 Verify that a call made by UA1 can initiate a server assignment by 598 vendor B for that call. Verify that the SIP INVITE also triggers 599 a location query (LIR/LIA exchange) with vendor B. Message flow 600 can be as follows. 602 +--------+ +--------+ +--------+ 603 | SIP | |Diameter| | SIP | 604 |server 1| | server | |server 2| 605 |Vendor A| |Vendor B| |Vendor D| 606 +--------+ +--------+ +--------+ 607 | | | 608 1. SIP INVITE | | | 609 -------------------->| 2. LIR | | 610 |------------------>| | 611 | 3. LIA | | 612 |<------------------| | 613 | | | 614 | 4. INVITE | | 615 |-------------------------------------->| 616 | | 5. SAR | 617 | |<------------------| 618 | | 6. SAA | 619 | |------------------>| 620 | | | 622 Figure 8: Message Flow for Session Initiation to a Non-registered 623 User 625 Normally, server selection is performed during this process. 626 Testers can verify if vendor A correctly determine vendor D as the 627 assigned SIP server. Additional service control functions may 628 also need to be performed by vendor D. Though those would be out 629 of scope of this document. 631 4.2. Diameter Sh 633 Implementations must conform to [TS29.328] and [TS29.329]. The test 634 topology for Diameter Sh is Figure 9. Because AS functionality is 635 implementation and service specific, it is left to the testers to 636 verify configuration of the provided service. UA registration with 637 AS services are also left up to the tester to verify. Some 638 interaction with the test topology for Section 4.1 maybe required in 639 certain test scenarios. 641 Home Network 643 +--------+ +--------+ 644 |Diameter| | AS | 645 IMS Network <---Cx--->| server |<--------->|Vendor E| 646 | |Vendor B| UDR/UDA | | 647 | +--------+ PUR/PUA +--------+ 648 | SNR/SNA | 649 | PNR/PNA | 650 | | 651 -------SIP to S-CSCF and UA1------- 653 Legend: 654 IMS Network - Test topology for Diameter SIP. 655 Network details are not shown 656 for brevity. 658 Diameter server - Vendor B acting HSS for Home Network. 659 Part of the IMS Network. 661 AS - Vendor E acting as AS 663 Figure 9: Diameter Sh Test Topology 665 The test topology shown above is an addendum to Figure 1. The AS 666 uses Diameter Sh with the HSS and SIP with S-CSCF and UA1 in the IMS 667 network. For Diameter Sh, the message flow being tested is defined 668 in Section B.1 of [TS29.328]. It is left to the testers to verify 669 that the AS is properly configured in the IMS network. 671 4.2.1. Required 673 The following are test scenarios to exercise Diameter Sh interface. 674 o Positive test for data handling. Implementations must conform to 675 Section 6.1.1 and 6.1.2 of [TS29.328]. Verify that vendor E is 676 capable of storing and retrieving service related data into vendor 677 B via PUR/PUA and UDR/UDA. If user1 in UA1 can register for 678 service to the vendor E, verify that vendor E is able to store 679 service related data into vendor B. If user1 can then register to 680 vendor D in the IMS network and trigger a third-party registration 681 to vendor E, verify that vendor E is able pull service related 682 data from vendor B. Verify correctness of the following identity- 683 set when reading data from vendor B. 684 * IMPLICIT_IDENTITIES 685 * REGISTERED_IDENTITIES 686 * ALL_IDENTITIES 688 o Positive test for subscription/notification. Implementations must 689 conform to Section 6.1.3 and 6.1.4 of [TS29.328]. Verify that 690 vendor E can successfully subscribe to notification in case of 691 data changes in vendor B. This test should be performed after the 692 previous positive test. Simulation of data changes in vendor B is 693 implementation specific. Verify that vendor B sends a PNR to E 694 when simulated changes occur. 695 o Negative test for data update. Verify behavior of both vendor B 696 and E when the criteria for following experimental result codes 697 are meet. 698 * DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED. Simulate update 699 restrictions for vendor E in vendor B. 700 * DIAMETER_ERROR_USER_UNKNOWN. 701 * DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions on 702 vendor B. Configuration of AS permission list maybe necessary. 703 * DIAMETER_PRIOR_UPDATE_IN_PROGRESS. 704 * DIAMETER_ERROR_TRANSPARENT_DATA_OUT_OF_SYNC. Simulation may 705 require some invalid configuration. 706 * DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some 707 invalid configuration. 708 o Negative test for data read and notification subscriptions. 709 Verify behavior of both vendor B and E when the criteria for 710 following experimental result codes are meet during data pull or 711 subscription. 712 * DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ. Simulate read 713 restrictions for vendor E in vendor B. 714 * DIAMETER_ERROR_USER_UNKNOWN. 715 * DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions on 716 vendor B. Configuration of AS permission list maybe necessary. 718 4.3. Diameter Rf 720 Implementations must conform to [TS32.260]. The test topology for 721 Diameter Rf is Figure 10. The test cases in this section do not 722 attempt to cover all accounting scenarios that are possible in an IMS 723 network. It only exercise accounting functions for test entities 724 listed in Figure 6. Because the test topology only describes a home 725 network, the Rf interface is limited to S-CSCF and I-CSCF accounting. 726 Record co-relation with a visited network is assumed not to be done. 727 The CDF entity should be reachable to the SIP servers in Figure 1 and 728 to the AS in Figure 9 if an AS is used. The test scenarios also 729 makes a lot of assumptions in testing non-Diameter related Rf 730 requirements such as the CDR formats, operator configuration of the 731 CDF, SIP based signaling or operator based decision on when to use 732 offline-charging etc. Since there can be a multitude of 733 configuration options, verification of actual billing schemes used 734 and its accuracy is left to the testers. 736 IMS Network 737 +----------+ 738 | | 739 <----ACR/ACA to SIP Server 1 ----->| CDF | 740 | Vendor F | 741 <----ACR/ACA to SIP Server 2 ----->| | 742 +----------+ 744 Legend: 745 IMS Network - Test topology for Diameter SIP and/or 746 Diameter Sh. Network details are not 747 shown for brevity. 749 CDF - Vendor F acting CDF for Home Network. 751 Figure 10: Diameter Rf Test Topology 753 4.3.1. Required 755 The following are test scenarios to exercise Diameter Rf interface. 756 o Positive test for SIP session establishment. Implementations must 757 conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or D 758 generates a START_RECORD on positive acknowledgment of SIP INVITE. 759 The SIP server involved depends on the UA location. The test 760 could be performed as part of Section 3.1.3. Note that only the 761 mandatory triggers are recommended to be tested. The remaining 762 triggers specified in Table 5.2.1.1 of [TS32.260] is left up to 763 the test pairs. 764 o Positive test for SIP session updates. Implementations must 765 conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or D 766 generates an INTERIM_RECORD on a SIP re-INVITE or UPDATE for an 767 existing SIP session. The test can be performed in sequence with 768 the previous positive test. 769 o Positive test for session-unrelated procedures. Implementations 770 must conform to Section 5.2.2.1.5 of [TS32.260]. Verify that 771 vendor A or D generates EVENT_RECORD on a SIP SUBSCRIBE signal. 772 The test can be performed in sequence with the previous positive 773 test. 774 o Positive test for SIP session termination. Implementations must 775 conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor D 776 generates STOP_RECORD on a SIP BYE signal. The test can be 777 performed in sequence with the previous positive test. 778 o Negative test for unsuccessful SIP session establishment. Verify 779 that if a SIP session establishment fails, that vendor A or D 780 generates an EVENT_RECORD. The SIP server involved depends on the 781 location of the UA initiating the session. 783 o Negative test for error cases. Verify that vendor A and/or D 784 follows Section 5.2.2.2 of [TS32.260]. The error cases in that 785 text are general and may overlap with error cases in the Diameter 786 Base Protocol Test Suite document. 788 4.3.2. Optional 790 The following are optional test scenarios to exercise Diameter Rf 791 interface. Note that details of the tests are skipped for brevity. 792 o Positive test for multi-party call. Assuming a new UA is 793 introduced in the home network and S-CSCF is provided by vendor D, 794 the call flow should follow Section 5.2.2.1.10 of [TS32.260]. 795 o Positive test for AS related procedures. If an AS is used, verify 796 that vendor E can generate EVENT_RECORDs for services rendered to 797 the UA. Such services are implementation specific. However, 798 examples of such service is described in Section 5.2.2.1.11 of 799 [TS32.260]. 801 5. Diameter EAP Test Suite 803 Access device and AAA servers that support Diameter EAP Application 804 must conform to [RFC4072]. A typical test for network access 805 authentication using Diameter EAP is shown in Figure 11. The User 806 has an EAP Client to be authenticated for network access. The test 807 cases only cover the NAS and Auth. Servers interoperability. To 808 perform these tests, one must choose an EAP method. It is 809 recommended to use an authentication method which derive keying 810 material to test key transport between Auth. Server and NAS. As an 811 example, EAP-TLS [RFC2716] can be used. 813 +--------+ +--------+ +---------------+ 814 | User |<--->| NAS |<--->| Auth Server 1 | 815 | | |Vendor A| | Vendor B | 816 +--------+ +--------+ +---------------+ 817 ^ 818 | 819 | 820 v 821 +---------------+ 822 | Auth Server 2 | 823 | Vendor C | 824 +---------------+ 826 Legend: 827 User 828 NAS - Vendor A Diam EAP client 829 Auth Server 1 - Vendor B Diam EAP server 830 Auth Server 2 - Vendor C Diam EAP server 832 Figure 11: Diameter EAP 834 5.1. Required 836 Implementation must conform to section 2 of [RFC4072]. NAS and Auth. 837 Servers advertises Diameter EAP support in their CER/CEA exchange. 839 5.1.1. Non-Roaming case 841 In this test, User, NAS and Auth. Server 1 belongs to the same 842 realm. 843 o Verify that all Diameter messages for a particular user contains 844 the same Session-Id AVP. 845 o Positive test for EAP initiation. Verify that the Auth. server 846 initiates an EAP session while receiving either a DER containing 847 an EAP-Payload AVP Empty (signifying an EAP-Start) or an EAP- 848 Payload AVP containing an EAP-Response of Type Identity (cf. 849 section 2.2 of [RFC4072]). 850 o Positive test for User-Name AVP. Verify that the User-Name AVP 851 sent in DER message by the NAS contains the value provided by the 852 User in the EAP exchange between User and NAS. 853 o Positive test for user registration. Verify that the Auth. server 854 1 can authenticate and authorize User given a proper configuration 855 (e.g. by using EAP-TLS method between the User and the Auth. 856 Server). Verify that the AAA message flows is correct (cf. 857 section 2.2 of [RFC4072]). 859 o Positive test for Key transport and configuration. If the EAP 860 authentication method derives keys, verify that the Auth. Server 861 correctly provide keying material to the NAS and that these keys 862 are correctly used between User and NAS. 863 o Positive test for session termination: User Disconnection. Verify 864 that if the User disconnects for the NAS, the NAS sends a STR 865 message to the Auth. Server. Verify that the Auth. Server 866 releases all state concerning this User. 867 o Positive test for session termination: Auth-lifetime expiration. 868 Verify that if the auth-lifetime expires, the NAS send a STR to 869 the Auth. server. Verify that the Auth. Server releases all 870 state concerning this User. 871 o Negative test for authentication. Verify that the Auth. Server 872 sends a DEA message containing a DIAMETER_AUTHENTICATION_REJECTED 873 result-code to the NAS if the User is not correctly authenticated. 875 5.1.2. Roaming scenario 877 In this scenario, User and Auth. Server 2 belongs to realmB while 878 NAS and Auth. Server 1 belongs to realm A. All tests described in 879 the Non-Roaming scenario must work. As we are in roaming scenario, 880 the following two tests should also be performed. 881 o Positive test for Diameter EAP Direct Routing. Verify that if NAS 882 is properly configured, it can directly send Diameter EAP messages 883 to Auth. Server 2. 884 o Positive test for Diameter EAP Proxy Routing. Verify that if NAS 885 and Auth. Servers are correctly configured, Diameter EAP messages 886 are exchanged between NAS and Auth. Server 2 through Auth. 887 Server 1. 889 5.2. Optional Authorization/Accounting Tests 890 o Positive test for Authorization AVPs. Verify that if some 891 authorizations are requested, the DEA containing the 892 DIAMETER_SUCCESS in the Result-Code AVP also contains appropriate 893 Authorization AVPs (cf. section 5 of [RFC4005]). 894 o Positive test for Accounting. Verify that NAS initiates 895 Accounting if authentication is successful and finishes it while 896 terminating the session. 897 o Positive test for re-authentication. Verify that the Auth. 898 Server can reauthenticate the User via the NAS. 899 o Positive test for Redirection. Verify that the Redirect Scenario 900 described in section 2.3.2 of [RFC4072] is supported. 902 6. Diameter NASREQ Test Suite 904 Access device that supports Diameter NASREQ extension must conform to 905 [RFC4005]. Typical test topology for single domain authentication 906 shown in Figure 12. The User entity typically employs PPP to access 907 the NAS and is normally implementation dependent. Since the test 908 cases covers only NAS and Auth Server interoperability, it is left to 909 the tester to verify correctness of the access method between User 910 and NAS and that this method is able to trigger creation of a NASREQ 911 client session in the NAS. 913 +--------+ +--------+ +-------------+ 914 | User |<--->| NAS |<--->| Auth Server | 915 | | |Vendor A| | Vendor B | 916 +--------+ +--------+ +-------------+ 918 Legend: 919 User - Simulated user 920 NAS - Vendor A Diam NASREQ client 921 Auth Sever - Vendor B Diam NASREQ server 923 Figure 12: Diameter NASREQ Test Topology 925 Another test topology can exist for testing Diameter/RADIUS gateways 926 as specified in Section 9 of [RFC4005]. This topology is available 927 for vendors implementing a translation gateway. It should simulate a 928 common deployment scenario where there is a prevalence of legacy 929 RADIUS access devices ([RFC2865]). Since the test cases covers 930 interoperability scenarios, validation must be done between NAS and 931 Gateway. As with Figure 12, it is left to the tester to verify 932 correctness of the access method between User and NAS. The test 933 cases involving Figure 12 is also relevant to validating Gateway and 934 Auth Server and should be used in this topology as well. 936 +--------+ +--------+ +---------+ +-------------+ 937 | User |<--->| NAS |<--->| Gateway |<--->| Auth Server | 938 | | | | |Vendor A | | Vendor B | 939 +--------+ +--------+ +---------+ +-------------+ 941 Legend: 942 User - Simulated user 943 NAS - Simulated or vendor RADIUS client 944 Gateway - Vendor A Diameter/RADIUS gateway 945 Auth Sever - Vendor B Diam NASREQ server 947 Figure 13: Translation Gateway Test Topology 949 6.1. Required 950 6.1.1. Auth Session 952 Implementations must conform to Section 2 of [RFC4005]. Test 953 topology Figure 12 can be used for these cases. These tests 954 typically involves a myriad of configuration options. At the least 955 an implementation must be able to grant access to a user with a 956 reasonable level of security given the test cases below. The minimum 957 test that should be performed is PPP CHAP and PPP EAP with MD5 958 method. These tests are heavily dependent on other parameters that 959 are implementation specific (username, password, medium type, 960 calling-station-id etc). It is left to the tester to verify 961 correctness of this process but it must conform to Section 2.1, 3.1 962 and 3.2 of [RFC4005]. This includes conformance to the use of 963 transport level security (TLS or IPsec) for signaling sensitive 964 information, i.e., passwords etc. Verification of test cases can be 965 done manually. 966 o Positive test for proper Auth server session establishment with 967 authorization and authentication. Verify that user can initiate 968 an access-request via vendor A and that vendor B can respond when 969 PPP negotiation begins. Vendor A and B can agree on the service- 970 type. Verify that at the least B can support auth-request-type 971 AUTHORIZE_AUTHENTICATE. 972 o Positive test for proper NAS session establishment with 973 authorization and authentication. Verify that user can initiate 974 an access-request via vendor A and that vendor B can respond when 975 PPP negotiation begins. Verify that A is able to support 976 DIAMETER_MULTI_ROUND_AUTH result-code. 977 o Positive test for proper NAS session establishment with PPP. 978 Verify support for PPP CHAP/EAP in auth request/answer exchanges. 979 Verify that call and session information are exchanged properly to 980 conform to Section 4.1 of [RFC4005]. 981 o Positive test for proper session termination. Verify that a NAS 982 can initiate termination upon user disconnection. Verify that the 983 auth server can abort a session. Must conform to Section 2.3 of 984 [RFC4005]. 985 o Positive test for installation of NAS-filter-rules. Filter rule 986 implementation should at least carry the form IPFilterType as 987 specified in Section 4.3 of [RFC3588]. Verify that the rules sent 988 by the auth server is installed properly in the NAS for the 989 specific user. Note that implementation extensions done to the 990 NAS-filter-rule can affect interoperability between peers. If 991 commonality or agreements among implementations regarding the 992 definition of NAS-filter-rule can be found and it deviates from 993 the specification, it should be duly noted and used as a basis for 994 specifying future NAS-filter-rule extensions. 995 o Negative test for session failure when service type is 996 unsupported. Verify that the auth server can terminate the 997 session with DIAMETER_INVALID_AVP_VALUE for an unsupported service 998 type. 1000 6.1.2. Diameter/RADIUS Gateway 1002 Implementations must conform to Section 9 of [RFC4005]. Test 1003 topology Figure 13 can be used for these cases. Validation of these 1004 tests maybe localized to the Gateway (vendor A) but for the purpose 1005 of interoperability, end-to-end authentication and/or authorization 1006 must succeed between User and Auth Server (vendor B). 1007 o Positive test for forwarding RADIUS request as Diameter request. 1008 Verify that Section 9.1 of [RFC4005] is followed and that 1009 transaction states are maintained by the Gateway on behalf of the 1010 RADIUS client. 1011 o Positive test for forwarding RADIUS response from Diameter 1012 responses. Verify that Section 9.1 of [RFC4005] is followed and 1013 the session generated from the original RADIUS request is 1014 maintained. 1015 o Negative test for terminating a Diameter session upon auth 1016 failure. Conditions for termination is specified in Section 9.1 1017 of [RFC4005]. 1019 6.1.3. Multi-domain Scenario 1021 Test cases in this section is synonymous to Section 6.1.1 and all 1022 requirements in that section apply here as well. These scenarios, 1023 however, uses Figure 1 of Diameter Base Protocol Test Suite Document 1024 instead. Vendor A1 can acts as the NAS and B1 or B2 can act as the 1025 auth server. A2 or B1 can act as either a proxy/agent or redirect 1026 agent for A1. As with the routing test in Diameter Base Protocol 1027 Test Suite, these tests are symmetric to both vendors. 1028 o Positive test for multi-domain auth using proxy/relay agent. 1029 Verify that A2 acting as a proxy/relay can reliably forward auth- 1030 request and answers between A1 and B2. All test cases enumerated 1031 in Section 6.1.1 must be performed. Note that this test cases 1032 overlap with the relay testing done in Diameter Base Protocol Test 1033 Suite. It must conform to all requirements of those test. 1034 o Positive test for multi-domain auth using redirect agent. Verify 1035 that A2 or B1 acting as a redirect can successfully respond with 1036 redirect information to A1. All test cases enumerated in 1037 Section 6.1.1 must be performed. Note that this test cases 1038 overlap with the relay testing done in Diameter Base Protocol Test 1039 Suite. It must conform to all requirements of those test. 1041 6.2. Optional 1043 Implementations must conform to Section 2 of [RFC4005]. Test 1044 topology uses Figure 12. These are optional test that 1045 implementations can perform. 1047 6.2.1. Auth Session 1049 Implementations must conform to Section 2 of [RFC4005]. These test 1050 cases are in support of Section 6.1.1. 1051 o Positive test for proper NASREQ accounting. Verify that 1052 accounting session is initiated by vendor A if supported by the 1053 implementation. Implementations must conform to Section 8 of 1054 [RFC4005]. 1055 o Positive test for session re-authentication if supported. Must 1056 conform to Section 2.2 of [RFC4005]. Behavior maybe dependent on 1057 implementation and policy however auth-lifetime and auth-grace- 1058 period must be utilized. Must conform to 8.3 of [RFC3588]. 1060 7. Diameter MIP Test Suite 1062 Vendors that support Diameter Mobile IPv4 extension must conform to 1063 [RFC4004]. There are typically several topologies that is possible 1064 when deploying Diameter MIP. Those which are more likely to be 1065 deployed are included in this document. The test cases are also 1066 highly dependent on the topologies themselves hence each test case 1067 provides its own test topology. Configuration of the mobility agents 1068 (Mobile, HA and FA) for all test cases are implementation specific 1069 and it is left up to the tester to verify their correctness. Testers 1070 must also verify that the MIP implementation conforms to Section 4 of 1071 [RFC4004] as it relates to Diameter. Testers must also ensure that 1072 all positive test resulting in successful authentication and/or 1073 authorization must generate appropriate session keys and MSAs as 1074 needed. It should conform to [RFC3957] and [RFC3012] as it applies. 1075 This is implementation and policy dependent but can be as a 1076 consequence of positive test cases so it is worthwhile to verify. 1078 7.1. Generic MIP Test Scenarios 1080 The following are generic test scenarios that can be applied to any 1081 MIP test topology. It is enumerated here for simplicity since it is 1082 common to all topology. 1083 o Positive test for mobile registration. Verify that at the least, 1084 the HA can authenticate and authorize the Mobile given the proper 1085 configuration (MIP authorization extensions. Verify that the AAA 1086 message flows for the specific topology is followed. Verify that 1087 proper key distribution occurs in the process. If accounting is 1088 supported, verify that accounting-sub-session-id is used. 1089 o Positive test for session termination. Verify that the expiration 1090 of auth-lifetime causes an STR to be sent from the HA and that the 1091 message flows are valid. Verify that the AAAH releases all 1092 session state it keeps if any. The AAAH must conform to Section 1093 4.1.3 of [RFC4004]. 1095 o Positive test for re-authentication. Verify that the Mobile can 1096 successfully performs re-authentication if policy allows. Verify 1097 that the AMR sent by the FA or Mobile on re-auth and carries the 1098 original session-id, HA NAI and AAAH NAI as appropriate. 1099 Implementations must conform to [RFC3846]. 1100 o Negative test for failed registration or authentication. Verify 1101 that a failed authentication or registration causes an STR to be 1102 sent from the HA and that DIAMETER_AUTHENTICATION_REJECTED result- 1103 code is communicated back to the FA or Mobile in the AMA. Verify 1104 that the AAAH releases all session state it keeps if any. AAAH 1105 must conform to Section 4.1.3 of [RFC4004]. 1107 7.2. Required 1109 7.2.1. Co-located Registration 1111 Implementation must conform to Section 3.3 of [RFC4004]. Test 1112 topology for co-located mobile node deployment is shown below in 1113 Figure 14. Both HA and AAAH share the same realm which can be a home 1114 or foreign realm of the Mobile. Verifying the correctness of the 1115 Mobile to HA registration is out of scope for this document is left 1116 to the tester. However, it must conform to [RFC3344] and its 1117 successor document. Note also that there is a myriad of 1118 configuration options for this test case and it is left to the test 1119 pairs to agree on which and on how many configuration can and should 1120 be tested. 1122 +--------+ +--------+ +-------------+ 1123 | Mobile |<--->| HA |<--->| AAAH | 1124 | | |Vendor A| | Vendor B | 1125 +--------+ +--------+ +-------------+ 1127 Legend: 1128 Mobile - Mobile is IPv4 mobile node 1129 HA - Vendor A as a MIP Home Agent 1130 AAAH - Vendor B as a Home AAA server 1132 Figure 14: Test Topology for Co-located Mobile Node 1134 o All test scenarios in Section 7.1 must be performed. 1136 7.2.2. Intra-Domain Registration 1138 Implementation must conform to [RFC4004]. The basic test topology 1139 for single domain registration is shown below in Figure 15. All 1140 entities share the same realm with FA and HA presiding over different 1141 networks. The topology can be a combination of different vendor 1142 implementations. Testers must verify that the AAA message flows in 1143 Figure 15 are followed for the registration process. 1145 +---------+ 1146 | AAAH | 1147 |Vendor B | 1148 +---------+ 1149 AMR/AMA / \ HAR/HAA 1150 / \ 1151 +---------+ +---------+ 1152 | FA | | HA | 1153 |Vendor A | |Vendor C | 1154 +---------+ +---------+ 1155 ^ 1156 | Mobile IP 1157 v 1158 +---------+ 1159 | Mobile | 1160 +---------+ 1162 Legend: 1163 Mobile - Mobile is IPv4 mobile node 1164 FA - Vendor A as a MIP Foreign Agent 1165 AAAH - Vendor B as a Home AAA server 1166 HA - Vendor C as a MIP Home Agent 1168 Figure 15: Test Topology for Intra-Domain MIP 1170 o All test scenarios in Section 7.1 must be performed. If [RFC3846] 1171 is supported, MIP NAIs should be used to route the AMRs towards 1172 the AAAH. 1173 o Positive test for handover. Verify that if Mobile performs a 1174 handover to HA that de-registration occurs properly and subsequent 1175 AMR/AMA exchanges are appropriate. Verify also that the 1176 accounting session is maintained if any. 1177 o Negative test for failed allocation of home agent. Vendor B can 1178 be configured not to provide a home agent for the Mobile. Verify 1179 that DIAMETER_ERROR_HA_NOT_AVAILABLE is sent by vendor B to vendor 1180 A. Verify that the B releases all session state it keeps if any. 1181 Vendor B must conform to Section 4.1.3 of [RFC4004]. 1183 7.2.3. Inter-Domain Registration 1185 Implementation must conform to Section 3.1 of [RFC4004]. The basic 1186 test topology for inter-domain registration is shown below in 1187 Figure 16. A1 and A2 reside in realmA and B1 and B2 reside in 1188 realmB. The entities in the topology can be a combination of 1189 different vendor implementations. Verifying the correctness of the 1190 Mobile to FA discovery and registration is implementation specific 1191 and out of scope of this document. It is left to the tester to 1192 validate this process but it must conform to requirements [RFC3344] 1193 and its successor document. As with previous test cases in Diameter 1194 MIP, there is a myriad of configuration options for this test case 1195 and it is left to the test pairs to agree on which and on how many 1196 configuration can and should be tested. However, testers must verify 1197 that the AAA message flows in Figure 16 are followed for the 1198 registration process regardless of configuration. 1200 realmA (visited) realmB (home) 1201 +---------+ +---------+ 1202 | AAAF | AMR/AMA | AAAH | 1203 |Vendor A2|<----------->|Vendor B2| 1204 +---------+ +---------+ 1205 ^ ^ 1206 AMR/AMA | | HAR/HAA 1207 v v 1208 +---------+ +---------+ 1209 | FA | | HA | 1210 |Vendor A1| |Vendor B1| 1211 +---------+ +---------+ 1212 ^ 1213 | Mobile IP 1214 v 1215 +---------+ 1216 | Mobile | mn@realmB.com 1217 +---------+ 1219 Legend: 1220 Mobile - Mobile is IPv4 mobile node 1221 FA - Vendor A1 as a MIP Foreign Agent 1222 AAAF - Vendor A2 as a Foreign AAA server 1223 AAAH - Vendor B2 as a Home AAA server 1224 HA - Vendor B1 as a MIP Home Agent 1226 Figure 16: Test Topology for Inter-Domain MIP 1228 o All test scenarios in Section 7.1 must be performed. If [RFC3846] 1229 is supported, MIP NAIs should be used to route the AMRs towards 1230 the AAAH. 1231 o Positive test for handover. Verify that if Mobile performs a 1232 handover to B1 that de-registration occurs properly and subsequent 1233 AMR/AMA exchanges are appropriate. Verify also that the 1234 accounting session is maintained if any. 1235 o Negative test for failed allocation of home agent. B2 can be 1236 configured not to provide a home agent for the Mobile. Verify 1237 that DIAMETER_ERROR_HA_NOT_AVAILABLE sent by B2 is propagated to 1238 FA via the AMA. Verify that the B2 releases all session state it 1239 keeps if any. B2 must conform to Section 4.1.3 of [RFC4004]. 1241 7.2.4. Allocation of HA in Foreign Network 1243 Implementation must conform to Section 3.2 of [RFC4004]. The basic 1244 test topology for dynamically allocated HA is shown below in 1245 Figure 17. A1, A2 and A3 reside in realmA and B1 resides in realmB. 1246 The entities in the topology can be a combination of different vendor 1247 implementations. Policies in AAAF and AAAH must support dynamic 1248 allocation of an HA. Testers must verify that the AAA message flows 1249 in Figure 17 are followed for the registration and HA allocation 1250 process. 1252 realmA realmB 1253 +---------+ ------- AMR ------> +---------+ 1254 | AAAF | <----- HAR -------- | AAAH | 1255 +--->|Vendor A3| ------- HAA ------> |Vendor B1| 1256 | +---------+ <----- AMA -------- +---------+ 1257 | ^ | 1258 | | | 1259 HAR/HAA | AMR | | AMA 1260 v | v 1261 +---------+ +---------+ 1262 | HA | | FA | 1263 |Vendor A2| |Vendor A1| 1264 +---------+ +---------+ 1265 ^ 1266 +--------+ Mobile IP| 1267 | Mobile |<----------+ 1268 +--------+ 1270 Legend: 1271 Mobile - Mobile is IPv4 mobile node 1272 FA - Vendor A1 as a MIP Foreign Agent 1273 AAAF - Vendor A3 as a Foreign AAA server 1274 AAAH - Vendor B1 as a Home AAA server 1275 HA - Vendor A2 as a MIP Home Agent 1277 Figure 17: Test Topology for Allocation of HA in Foreign Network 1279 o All test scenarios in Section 7.1 must be performed. If [RFC3846] 1280 is supported, MIP NAIs should be used to route the AMRs towards 1281 the AAAH. For test scenarios resulting in the termination of the 1282 session, verify that the HA allocated in A2 is released if policy 1283 permits. 1284 o Negative test for failed allocation of home agent. B1 can be 1285 configured not to provide a home agent for the Mobile. Verify 1286 that DIAMETER_ERROR_HA_NOT_AVAILABLE sent by B1 is propagated to 1287 A1. Verify that the B1 releases all session state it keeps if 1288 any. B1 must conform to Section 4.1.3 of [RFC4004]. 1290 7.3. Optional 1292 Vendors that support Diameter Mobile IPv4 extension must conform to 1293 [RFC4004]. The following are optional test cases that can be 1294 performed for Diameter MIP. 1296 7.3.1. Co-located Registration via Redirect Indication 1298 An addendum to the topology shown in Figure 16 is shown in Figure 18. 1299 The redirect agent is introduced if additional transport security is 1300 required between HA and AAAH in the co-located scenario as described 1301 in Section 3.3 of [RFC4004]. Optional IPsec or TLS connectivity can 1302 be established between HA and AAAH. For simplicity Figure 18 differs 1303 from Figure 8 of [RFC4004] by not having an AAA proxy but relying on 1304 the redirect agent directly. 1306 +----------+ 1307 | Redirect | 1308 | Vendor B1| 1309 +----------+ 1310 | 1311 | 1312 +--------+ +--------+ +-------------+ 1313 | Mobile |<--->| HA |<--->| AAAH | 1314 | | |Vendor A| | Vendor B2 | 1315 +--------+ +--------+ +-------------+ 1317 Legend: 1318 Mobile - Mobile is IPv4 mobile node 1319 HA - Vendor A as a MIP Home Agent 1320 Redirect - Vendor B1 redirect agent 1321 AAAH - Vendor B2 as a Home AAA server 1323 Figure 18: Test Topology for Co-located Mobile Node with Redirect 1325 o Positive test for mobile registration. Verify that redirection 1326 occurs between HA and Redirect agent. Verify that a secure 1327 transport is established between HA and AAAH. Verify that at the 1328 least, vendor B2 can authenticate and authorized the Mobile given 1329 the proper configuration. 1330 o Verify that the all test cases in Section 7.2.1 is be applied in 1331 this test case as well. 1333 7.3.2. Inter-Domain Registration with Redirect 1335 An addendum to the topology shown in Figure 16 is shown in Figure 19. 1336 The redirect agent B3 is introduced if additional transport security 1337 is required and the use of an AAAF can be skipped. In this topology 1338 B3 shares the same realm a B1 and B2. Optional IPsec or TLS 1339 connectivity can be established between A1 and B2 as describe in 1340 Figure 3 of [RFC4004]. However, the secure connectivity can be 1341 omitted to simplify testing. 1343 +---------+ 1344 |Redirect | 1345 |Vendor B3| 1346 +---------+ 1347 / 1348 realmA (visited) / realmB (home) 1349 +---------+ +---------+ 1350 | AAAF | AMR/AMA | AAAH | 1351 |Vendor A2| -------|Vendor B2| 1352 +---------+ / +---------+ 1353 ^ / ^ 1354 AMR/AMA | / | HAR/HAA 1355 v / v 1356 +---------+ / +---------+ 1357 | FA | | HA | 1358 |Vendor A1| |Vendor B1| 1359 +---------+ +---------+ 1360 ^ 1361 | Mobile IP 1362 v 1363 +---------+ 1364 | Mobile | mn@realmB.com 1365 +---------+ 1367 Legend: 1368 Mobile - Mobile is IPv4 mobile node 1369 FA - Vendor A1 as a MIP Foreign Agent 1370 AAAF - Vendor A2 as a Foreign AAA server 1371 AAAH - Vendor B2 as a Home AAA server 1372 HA - Vendor B1 as a MIP Home Agent 1373 Redirect - Vendor B3 as a Redirect agent in reamlA 1375 Figure 19: Test Topology for Inter-Domain MIP with Redirect 1377 o Positive test for mobile registration. Verify that at the least, 1378 B1 acting as HA can authenticate and authorize the Mobile given 1379 the proper configuration. Verify that a secure transport is 1380 established between A1 and B2 if used. If accounting is 1381 supported, verify that accounting-sub-session-id is used. If 1382 [RFC3846] is supported, MIP NAIs should be used to route the 1383 message towards the HA. 1384 o Positive test for handover. Verify that if Mobile performs a 1385 handover to B1 that de-registration occurs properly and subsequent 1386 AMR/AMA exchanges are appropriate. Verify also that the 1387 accounting session is maintained if any. 1388 o Verify that the all test cases in Section 7.2.3 is be applied in 1389 this test case as well. 1391 7.3.3. Inter-Domain Registration with Proxy/Relay 1393 An addendum to the topology shown in Figure 16 is shown in Figure 20. 1394 The proxy/relay agent B3 exists between A2 and B2. In this topology 1395 B3 shares the same realm as B1 and B2. 1397 +------------+ 1398 |Proxy/Relay | 1399 |Vendor B3 | 1400 +------------+ 1401 / AMR/AMA \ 1402 realmA (visited) / \ realmB (home) 1403 +---------+ +---------+ 1404 | AAAF | | AAAH | 1405 |Vendor A2| |Vendor B2| 1406 +---------+ +---------+ 1407 ^ ^ 1408 AMR/AMA | | HAR/HAA 1409 v v 1410 +---------+ +---------+ 1411 | FA | | HA | 1412 |Vendor A1| |Vendor B1| 1413 +---------+ +---------+ 1414 ^ 1415 | Mobile IP 1416 v 1417 +---------+ 1418 | Mobile | mn@realmB.com 1419 +---------+ 1421 Legend: 1422 Mobile - Mobile is IPv4 mobile node 1423 FA - Vendor A1 as a MIP Foreign Agent 1424 AAAF - Vendor A2 as a Foreign AAA server 1425 AAAH - Vendor B2 as a Home AAA server 1426 HA - Vendor B1 as a MIP Home Agent 1427 Redirect - Vendor B3 as a Redirect agent in reamlA 1429 Figure 20: Test Topology for Inter-Domain MIP with Proxy/Relay 1431 o Positive test for mobile registration. Verify that at the least, 1432 B1 acting as HA can authenticate and authorize the Mobile given 1433 the proper configuration. Verify that B3 can reliably relay AMR/ 1434 AMA exchanges between A1 and A2. If accounting is supported, 1435 verify that accounting-sub-session-id is used. If [RFC3846] is 1436 supported, MIP NAIs should be used to route the message towards 1437 the HA. 1438 o Verify that the all test cases in Section 7.2.3 is be applied in 1439 this test case as well. 1440 o Positive test for handover. Verify that if Mobile performs a 1441 handover to B1 that de-registration occurs properly and subsequent 1442 AMR/AMA exchanges are appropriate. Verify also that the 1443 accounting session is maintained if any. 1445 8. Security Considerations 1447 This document defines test cases and therefore tests various aspects 1448 of the Diameter base specification and various Diameter applications. 1450 9. IANA Considerations 1452 This document does not require actions by IANA. 1454 10. Normative References 1456 [I-D.ietf-aaa-diameter-sip-app] 1457 Garcia-Martin, M., "Diameter Session Initiation Protocol 1458 (SIP) Application", draft-ietf-aaa-diameter-sip-app-12 1459 (work in progress), April 2006. 1461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1462 Requirement Levels", BCP 14, RFC 2119, March 1997. 1464 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1465 Protocol", RFC 2716, October 1999. 1467 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1468 "Remote Authentication Dial In User Service (RADIUS)", 1469 RFC 2865, June 2000. 1471 [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ 1472 Response Extensions", RFC 3012, November 2000. 1474 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1475 A., Peterson, J., Sparks, R., Handley, M., and E. 1476 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1477 June 2002. 1479 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1480 August 2002. 1482 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1483 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1485 [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for 1486 Carrying Network Access Identifiers", RFC 3846, June 2004. 1488 [RFC3957] Perkins, C. and P. Calhoun, "Authentication, 1489 Authorization, and Accounting (AAA) Registration Keys for 1490 Mobile IPv4", RFC 3957, March 2005. 1492 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 1493 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1494 August 2005. 1496 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1497 "Diameter Network Access Server Application", RFC 4005, 1498 August 2005. 1500 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1501 Authentication Protocol (EAP) Application", RFC 4072, 1502 August 2005. 1504 [TS29.228] 1505 3GPP, "IMS Cx and Dx interfaces : signalling flows and 1506 message contents", 3GPP TS 29.228 Version 7.0.0 2006. 1508 [TS29.229] 1509 3GPP, "IMS Cx and Dx interfaces based on the Diameter 1510 protocol; Protocol details", 3GPP TS 29.229 Version 1511 7.0.0 2006. 1513 [TS29.328] 1514 3GPP, "IMS Sh interface : signalling flows and message 1515 content", 3GPP TS 29.328 Version 6.8.0 2005. 1517 [TS29.329] 1518 3GPP, "IMS Sh interface based on the Diameter protocol; 1519 Protocol details", 3GPP TS 29.329 Version 6.6.0 2005. 1521 [TS32.260] 1522 3GPP, "IP Multimedia Subsystem (IMS) Charging", 3GPP TS 1523 32.260 Version 6.4.0 2005. 1525 Authors' Addresses 1527 Victor Fajardo 1528 Telcordia Technologies 1529 1 Telcordia Drive #1S-222 1530 Piscataway, NJ 08854 1531 USA 1533 Email: vfajardo@research.telcordia.com 1535 Alan McNamee 1536 Openet Telecom Inc 1537 6 Beckett Way, Park West Business Park 1538 Clondalkin, Dublin 12 1539 Ireland 1541 Phone: +353 1 620 4600 1542 Email: alan.mcnamee@openet-telecom.com 1544 Hannes Tschofenig 1545 Nokia Siemens Networks 1546 Linnoitustie 6 1547 Espoo 02600 1548 Finland 1550 Phone: +358 (50) 4871445 1551 Email: Hannes.Tschofenig@gmx.net 1552 URI: http://www.tschofenig.priv.at 1554 Julien Bournelle 1555 France Telecom R&D 1556 38-4O rue du general Leclerc 1557 Issy-Les-Moulineaux 92794 1558 France 1560 Email: julien.bournelle@orange-ftgroup.com