qualcomm incorporated 1 protocol options for bsn- bsmcs controller interface jun wang, kirti gupta...

1

QUALCOMM Incorporated

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


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

BCMCSController

MR S-AAABSC PCF BSNMS2MS1

Pre provisioned Flow+ receiving area

*RADIUS Ext/SAP message

(NAS IP Address,BCMCS session

Info, PCF, BSC, BTSIDs etc.)

*Message ACK*Message ACK

*RADIUS Ext/SAP message (NAS IPAddress, BCMCS session Info, PCF, BSC,

BTS IDs etc.)

IGMP JoinRFC 2236

Flow Start time

CS

ContactRAN_IDs

A11-BC-RegistrationRequest

A9-BC-Setup A8

A11-BC-RegistrationReply

A9-BC-connect

A8

* Either the RADIUS extension CoA-Auth and CoA-ACK messages (RFC 3576) or SAP (RFC2974) can be used

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


SAP Header Format

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

announcementOriginating Source Address

• IP address of original source of message

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


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


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


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


Change-of-Authorization (CoA) messages

The NAS responds to a CoA-Request sent by RADIUS server withCoA-ACK if the NAS is able to successfully change the authorizationsfor the user session, or CoA-NAK if the Request is unsuccessful.

11


Packet format for CoA messages

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


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


Conclusion

• A group decision is required to move forward – by weighing the pros and cons of each protocol

qualcomm incorporated 1 protocol options for bsn- bsmcs controller interface jun wang, kirti gupta...

Documents