1. QUALCOMM Incorporated 1 Protocol Options for BSN- BSMCS Controller Interface Jun Wang, Kirti Gupta 05/16/2005 Notice: Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Contributors. Contributors specifically reserve the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of contributors other than provided in the copyright statement above.

2. QUALCOMM Incorporated 2 Network Initiated Bearer Setup – Proposed for X.P0022-A

3. QUALCOMM Incorporated 3 SAP (Session Announcement Protocol) – RFC 2974 Experimental RFC Multicast announcement of session description information Periodically send SAP packets to a well known multicast IP address/port Mandate use of port 9875 for SAP Multiple session descriptions/SAP packets may be sent over the same multicast IP address/port A session announcement is identified by Message ID hash and Originating Source (IP addr) field in SAP header Session description information may be changed at any time A new SAP message is sent with different Message ID value. A Session is identified by the payload.

4. QUALCOMM Incorporated 4 SAP Header Format

5. QUALCOMM Incorporated 5 Description of SAP header fields V: Version Number (Set to 1) A: Address Type Set to 0 if Originating Source contains IPv4 address Set to 1 if Originating Source contains IPv6 address R: Reserved (Set to 0) T: Message Type Set to 0 if session announcement packet Set to 1 if session deletion packet E: Encryption bit Set to 1 if SAP payload is encrypted C: Compressed bit Set to 1 if SAP payload is compressed using zlib compression Authentication Length Size of authentication data following SAP header (in 32-bit words) Authentication Data digital signature of packet Message Identifier Hash 16-bit quantity used with originating source to provide a globally unique ID for session announcement Originating Source Address IP address of original source of message

6. QUALCOMM Incorporated 6 SAP Payload Optional Payload Type field omitted if payload type is application/sdp Mandatory for SAP senders and receivers to support payload type application/sdp Other payload type formats may be supported However, no negotiation defined in SAP allowing receivers to know the capabilities of the senders For BCMCS Controller-> BSN Interface: SDP defined in BCMCS Info Acquisition can be sent as payload + other data (if required)

7. QUALCOMM Incorporated 7 Encrypted SAP Announcements Per RFC: encrypted SAP is useful in certain cases only; such cases may be better served by using another mechanism for distributing session announcements RFC does not specify an encryption algorithm or means to distribute/generate keys If a key exchange mechanism is in place (preconfigured), Auth header may be used for: Verification of changes to session description or deletion Authentication of identity of session creator Is this required for BCMCS Controller->BSN Interface? Not required because no key information (BAK etc.) is sent on this interface Does any other session related information need to be encrypted? (e.g.: transmission area, schedule?) Do we need integrity check for contents being sent on this interface?

8. QUALCOMM Incorporated 8 Pros and Cons of using SAP Pros: Can multicast the session description to several BSNs Cons: Support of a new protocol at the BSN and BCMCS controller IETF enhancements required for SDP All BSNs subscribed to the group receive session announcement, even if not interested Note: May need SDP enhancements in IETF to support BCMCS information, e.g: QoS information, transmission area

9. QUALCOMM Incorporated 9 RADIUS Extensions RFC 3576: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Current RADIUS protocol does not support msgs initiated from RADIUS Server to RADIUS client Several vendors have implemented additional commands for called Change-of-Authorization (CoA) commands Informational RFC because of Incompatibilities with existing implementations – not backward compatible Security vulnerabilities – use per-packet authentication with known weakness; may be overcome by using IPSec Semantic ambiguities – cannot distinguish between CoA Auth request for session identification or authorization change

10. QUALCOMM Incorporated 10 Change-of-Authorization (CoA) messages The NAS responds to a CoA-Request sent by RADIUS server with CoA-ACK if the NAS is able to successfully change the authorizations for the user session, or CoA-NAK if the Request is unsuccessful.

11. QUALCOMM Incorporated 11 Packet format for CoA messages

12. QUALCOMM Incorporated 12 Description of RADIUS Extension header fields Code: (1 byte) identifies type of RADIUS packet. RADIUS codes (decimal) for this extension are: 40 - Disconnect-Request [RFC2882] 41 - Disconnect-ACK [RFC2882] 42 - Disconnect-NAK [RFC2882] 43 - CoA-Request [RFC2882] 44 - CoA-ACK [RFC2882] 45 - CoA-NAK [RFC2882] Identifier: Aids in matching requests and replies Length: Length of the entire packet including header fields Authenticator: to authenticate msgs b/w RADIUS servers and clients Attributes: Defined in Section 3 of RFC for all message types

13. QUALCOMM Incorporated 13 Pros and Cons of using RADIUS Pros: The BSN and BCMCS Controller already support the RADIUS protocol Reuse of existing RADIUS attributes specified in X.P0022 –No additional attributes may be required: Common Session Info, BSN Session Info, RAN Session Info, Subnet, SID/NID/PZID already specified in X.P0022. Cons: This mechanism only works if (a) A session already exists between BSN and AAA or (b) the IP address of the AAA is known to the BSN Cannot multicast the session description to several BSNs Note: If additional RADIUS attributes needed, can be defined in 3GPP2

14. QUALCOMM Incorporated 14 Conclusion A group decision is required to move forward – by weighing the pros and cons of each protocol