2.1.1 Đăng ký
Khái quát sự đăng ký
Hình 2.1. Quá trình đăng ký. [9]
UE muốn sử dụng một dịch vụ trong IMS thì trước hết nó phải tìm được một P-CSCF (*) và đăng ký để đạt được kênh mang kết nối IP với P-CSCF đó. Trường hợp truy nhập GPRS, UE thực hiện thủ tục liên lạc với GPRS và thực hiện thủ tục PDP Context (Packet Data Protocol ** ) cho báo hiệu SIP. Sự đăng ký IMS gồm hai giai đoạn (phía trái hình 2.1 là giai đoạn đầu – chỉ cách mạng truy vấn UE, bên phải hình 2.1 chỉ ra giai đoạn 2 – cách UE phản hồi sự truy vấn đó và hoàn thành sự đăng ký).
Đầu tiên, UE gửi một yêu cầu SIP REGISTER đến P-CSCF (đã tìm được ở thủ tục tìm kiếm P-CSCF). Yêu cầu này chứa một nhận dạng cần được đăng ký và một tên miền thường trú (hoặc địa chỉ của I-CSCF). Sau khi chọn được S-CSCF, I-CSCF chuyển tiếp yêu cầu REGISTER cho S-CSCF. S-CSCF sẽ nhận ra User đó chưa được trao quyền và vì thế S- CSCF gọi dữ liệu nhận thực về User đó từ HSS (Hình 2.1 và mục 1.3.3 - giao diện Cx, Dx) và chấp vấn User bằng bản tin phản hồi 401 Unauthorized (không cho phép) .
Hình 2.2. I-CSCF tìm S-CSCF [9]
Tiếp theo, UE sẽ phản hồi bằng cách gửi yêu cầu REGISTER khác đến P-CSCF. P- CSCF sẽ tìm ra I-CSCF và I-CSCF sẽ tìm ra S-CSCF. Cuối cùng S-CSCF kiểm tra phản hồi (REGISTER đó) của UE, nếu nó đúng với các mô tả thuộc tính User tải về từ HSS thì S- CSCF sẽ chấp nhận đăng ký và phản hồi UE một bản tin 200 OK (đồng thời nó cũng thông báo với HSS về sự nhận thực và trao quyền này bằng bản tin SAR, xem mục 1.3.3.4- Tham chiếu Cx). Khi UE đăng ký thành công, nó có thể khởi tạo và nhận được các phiên. Trong thủ tục đăng ký, cả UE và P-CSCF sẽ nghiên cứu xem S-CSCF nào trong mạng sẽ phục vụ UE. Những phản hồi của UE sẽ giúp duy trì sự đăng ký.
HSS I-CSCF P-CSCF S-CSCF 16. 200 OK 9 - 10. REGISTER 14 - 15. 200 OK 12. REGISTER 13. User profile 11. Find S-CSCF 1 - 2. REGISTER 4. REGISTER 5. Authentication data 8. 401 3. S-CSCF assignment 6 – 7. 401 HSS I-CSCF P-CSCF S-CSCF Hình 2.3. Sự đăng ký IMS [9]
(*) Dò tìm điểm vào mạng IMS P-CSCF – tức là UE cần có được địa chỉ IP của P-CSCF.
Theo 3GPP thì có hai cơ chế để đạt được địa chỉ IP này: thủ tục DHCP DNS (Dynamic
Host Configuration Protocol's Domain Name System) và thủ tục GPRS.
Thủ tục GPRS (hình 2.4), UE đặt cờ yêu cầu địa chỉ P-CSCF trong yêu cầu kích hoạt PDP Context (hoặc trong yêu cầu kích hoạt PDP Context thứ cấp) và UE sẽ nhận được địa chỉ IP của P-CSCF trong bản tin phản hồi (hoặc các địa chỉ IP nếu có nhiều P-CSCF nhận
được yêu cầu kích hoạt này) (3 GPP TS 24.008 để biết thêm cấu hình giao thức truyền thông tin yêu cầu này). Cơ chế mà GGSN lấy được địa chỉ IP của P-CSCF vẫn chưa được chuẩn hóa, nó không hoạt động đối với các GGSN tiền phiên bản 5.
Hình 2.4. Dò tìm P-CSCF bằng cơ chế GPRS. [3]
Thủ tục DHCP DNS (hình 2.5), UE gửi một truy vấn DHCP đến mạng truy nhập kết nối IP (ví dụ GPRS). Theo RFC3319 và RFC3315, UE có thể yêu cầu một danh sách các tên miền SIP Server của các P-CSCF hoặc yêu cầu một danh sách các địa chỉ IPv6 SIP Server của các P-CSCF. Khi các tên miền được gửi lại UE, thì UE cần thực hiện truy vấn DNS (NAPTR/SRV) để tìm ra một địa chỉ IP của P-CSCF.
Hình 2.5. Dò tìm P-CSCF bằng cơ chế thông thƣờng – DHCP DNS. [3]
(**) PDP - có 4 thủ tục đối với PDP Context:
Kích hoạt PDP Context sơ cấp (thủ tục tạo kết nối logic theo QoS từ UE tới GGSN), được khởi tạo bởi UE để kích hoạt trạng thái quản lý phiên, từ đó UE sẽ nhận được địa chỉ IP và các tài nguyên vô tuyến. Sau khi kích hoạt PDP Context cơ sở, UE có thể gửi các gói IP qua môi trường vô tuyến.
Kích hoạt PDP Context thứ cấp cho phép thuê bao thiết lập PDP Context thứ cấp với cùng địa chỉ IP như đã đạt được từ kích hoạt PDP Context sơ cấp. Hai Context này có thể có các đặc tính QoS khác nhau tùy thuộc vào ứng dụng mà có các yêu cầu QoS phù hợp.
Sửa đổi PDP Context là thủ tục mà UE, SGSN hoặc GGSN khởi tạo cho việc cập nhật PDP Context. Mạng truy nhập vô tuyến có thể yêu cầu thủ tục này ví dụ khi mất sóng với UE. Vô hiệu PDP Context là thủ tục dùng để xóa kết nối logic giữa UE và GGSN. Nó có thể được khởi tạo bởi UE, SGSN, HLR hoặc GGSN.
2.1.2. Nhận thực
Hình 2.2 ở trên mô tả về quá trình đăng ký, trong đó bao hàm cả sự nhận thực user. Khi S-CSCF nhận được yêu cầu REGISTER đăng ký, nó tải về vector nhận thực AV (authentication vector) từ HSS (bằng cách gửi SAR đến HSS và nhận về SAA, đã đề cập ở
mục 2.1.1). AV chứa RAND (chuỗi số ngẫu nhiên), XRES (kết quả so sánh với RES từ UE),
AUTN (network authentication token), IK (integrity key) và CK (ciphering key). S-CSCF sẽ phản hồi bằng cách gửi 401 Unauthorized chứa RAND, AUTN, IK và CK trở lại phía UE.
P-CSCF nhận được phản hồi này, nó sẽ xóa IK và CK rồi gửi phản hồi đến UE. IK được dùng cho việc kết hợp bảo mật giữa P-CSCF và UE (trình bầy trong vấn đề quản lý phiên).
Sau khi nhận được 401 Unauthoried, UE thẩm tra AUTN dựa trên IK và SQN có trong ISIM. Sự thẩm tra AUTN thành công đồng nghĩa với việc mạng được nhận thực (đảm bảo dữ liệu nhận thực nhận được đúng từ mạng thường trú của UE). UE thực hiện tính toán RES (authentication challenge response) dựa trên CK và RAND, rồi gửi RES ở yêu cầu REGISTER thứ cấp lại cho S-CSCF. S-CSCF sẽ thực hiện so sánh XRES nhận được từ HSS với RES nhận được từ UE, nếu thành công thì UE được nhận thực và tiếp tục thực hiện các thủ tục khác (các tham số nhận thực sẽ được nằm trong các bản tin khác cho đến khi kết thúc dịch vụ).
2.1.3. Vấn đề tính cƣớc: IMS hỗ trợ cả việc tính cước offline và online.
Cấu trúc tính cƣớc offline
Hình 2.6. Cấu trúc tính cƣớc offline IMS [3]
Phần tử chức năng trung tâm của cấu trúc tính cước offline là CCF (Charging Collection Function). CCF nhận các thông tin tài khoản từ các thực thể IMS qua giao diện Rf (điểm tham chiếu Rf), xử lý các dữ liệu nhận được thành dạng bản ghi dữ liệu cước CDR (Charging Data Record). CDR sẽ được gửi đến hệ thống lập hóa đơn.
Thu thập thông tin tài khoản từ các thực thể IMS và tạo thông tin tính cước theo định dạng CDR phù hợp. (adsbygoogle = window.adsbygoogle || []).push({});
Gửi CDR đến hệ thống tính cước lập hóa đơn.
Lưu trữ tạm thời CDR nếu hệ thống tính cước lập hóa đơn đang bận.
CCF có thể được triển khai tập trung hay phân tán hoặc là chức năng tích hợp trong các thực thể IMS.
CGF – Charging Gateway Funtion cung cấp cơ chế truyền thông tin tính cước từ SGSN và GGSN đến các hệ thống tính cước đã được nhà khai thác mạng chọn. Hệ thống tính cước (Billing system) có nhiệm vụ tạo các hóa đơn để gửi tới thuê bao hàng tháng.
Điểm tham chiếu Rf
Thông tin tính cước được gửi từ các thực thể IMS đến CCF nhờ các yêu cầu Diameter Accounting (ACR) qua giao diện Rf. Tất cả các thực thể liên quan đến quản lý phiên (ví dụ I- CSCF) gửi các Session ACR (được gửi thông báo về trạng thái bắt đầu, chuyển tiếp, kết thúc phiên ở các CDR). Các thực thể liên quan đến việc điều khiển phiên (như MRFC) gửi các Event ACR (gửi thông báo chung).
Bất cứ khi nào nhận được SIP 200 OK hoặc MRFC nhận được ISUP answer, thì ACR start được gửi đến CCF. Và bất cứ khi nào nhận được SIP BYE hoặc MGCF nhận được ISUP Release, thì ACR stop được gửi đến CCF.
Bảng 2.1. Bảng tham chiếu các bản tin tính cƣớc offline
Tên lệnh Mục đích Viết tắt Nguồn Đích
Yêu cầu tính cước
ACR được sử dụng để báo cáo/dừng thông tin tính cước tới CCF ACR S-CSCF, I-CSCF, P-CSCF, MRFC, MGFC, BGCF, AS CCF Trả lời tính cước ACA được sử dụng để xác nhận ACR và báo cáo kết quả
ACA CCF
S-CSCF, I-CSCF, P-CSCF, MRFC, MGCF, BGCF, AS
Điểm tham chiếu Bi
CCF dùng Bi để truyền các CDR đến hệ thống tính lập hóa đơn. Giao diện này dùng giao thức FTP trên nền TCP/IP [3GPP TS 32.225] do vậy có thể truyền các CDR khác nhau qua Bi. Các loại CDR: S-CSCF—CDR, I-CSCF—CDR, P-CSCF—CDR, BGCF—CDR, MGCF—CDR, MRFC—CDR, AS—CDR.
Cấu trúc tính cƣớc online
S-CSCF, AS và MRFC là các thực thể thực hiện việc tính cước online. AS và MRFC dùng điểm tham chiếu Ro, S-CSCF dùng điểm tham chiếu ISC (IMS Server Control) để thông tin với hệ thống tính cước online OCS.
Hình 2.7: Hệ thống tính cƣớc online trong IMS. [3] Event Charging Function (ECF)
Khi UE yêu cầu gì từ AS hay MRFC, AS hay MRFC liên lạc với ECF qua giao diện Ro trước khi cấp phát dịch vụ cho UE (AS hoặc MRFC nhận được địa chỉ của ECF từ S- CSCF cấp tại mào đầu P-Charging-Function-Address). Ở IMS Release 5 thì AS hoặc MRFC liên lạc với ECF bằng ACR và ACA, còn Release 6 thì AS hoặc MRFC liên lạc với ECF bằng CCR (Credit Control Request) và CCA (Credit Control Answer) ECF hỗ trợ hai chế độ trao quyền khác nhau: tính cước sự kiện ngay lập tức và tính cước sự kiện dành riêng.
Ở chế độ tính cước sự kiện ngay lập tức (IEC – Immediate Event Charging), ECF dùng Rating Function để tìm bảng giá phù hợp cho sự kiện. Sau khi tìm được bảng giá và tính giá, ECF sẽ trừ đi một lượng tiền trong tài khoản của User và cấp cho AS hoặc MRFC các ACRs tương ứng.
Ở chế độ tính cước sự kiện với đơn vị rành riêng (ECUR – Event Charging with Unit Reservation), ECF dùng Rating Function để xác định giá của dịch vụ muốn dùng theo thông tin dịch vụ. Sau đó ECF dự trữ một lượng tiền trong tài khoản của User và trả lại UE lượng tài nguyên tương ứng ở AS hoặc MRFC.
Session Charging Function (SCF)
SCF thực hiện tính cước theo sự sử dụng tài nguyên phiên, dựa trên các yêu cầu đã nhận được từ S-CSCF qua điểm tham chiếu ISC. SCF có thể điều khiển sự thiết lập phiên bằng cách cho phép hoặc từ chối yêu cầu thiết lập phiến sau khi kiểm tra tài khoản của User. SCF có thể kết thúc phiên đang tồn tại khi tài khoản của User đã cạn. SCF hỗ trợ chế độ tính cước sự kiện với đơn vị dự trữ.
Kênh mang Charging Function (CF)
SGSN dùng điểm tham chiếu liên quan tới CAMEL AP (CAP) cho việc yêu cầu sự chấp thuận cho dùng kênh mang từ BCF. BCF điều khiển cách dùng kênh mang.
Điểm tham chiếu Ro
AS và MRFC dùng các bản tin ACR và ACA của giao thức DIAMETER cho việc gửi thông tin tài khoản online qua điểm tham chiếu Ro đến ECF. Khi AS hoặc MRFC áp dụng chế độ tính cước sự kiện trực tiếp, một ACR event được dùng để ghi thông tin tài khoản tới ECF; Ở
chế độ thư hai, ACR Start, Interim và Stop được dùng cho dữ liệu tài khoản liên quan tới các phiên SIP không thành công.
Tên Lệnh Mục đích Viết tắt Nguồn Đích
Accounting - Request ACR được sử dụng để thông báo hoặc ngừng thông tin tính cước tới CCF (adsbygoogle = window.adsbygoogle || []).push({});
ACR MRFC, AS ECF
Accounting - Answer ACA được sử dụng để xác nhận ACR và thông báo kết quả
ACA ECF MRFC, AS
Bảng 2.2. Bảng tham chiếu các bản tin tính cƣớc online 2.2 BẢO MẬT TRONG IMS
Bảo mật trong IMS được chia thành hai loại: bảo mật cho truy nhập và bảo mật cho mạng. Bảo mật cho truy nhập gồm nhận thực user và nhận thực mạng, và sự bảo vệ cho lưu lượng giữa đầu cuối IMS và mạng. Bảo mật mạng giải quyết cho vấn đề bảo mật lưu lượng giữa các nút mạng (có thể giống nhau đối với các mạng khác nhau).
2.2.1 Bảo mật cho sự truy nhập
Một User truy nhập mạng IMS cần phải được nhận thực và trao quyền trước khi dùng một dịch vụ IMS nào. Khi User được trao quyền, chúng bảo vệ lưu lượng SIP giữa UE và P- CSCF nhờ cơ chế kết hợp bảo mật IPsec.
Sự thiết lập kết hợp bảo mật: P-CSCF và đầu cuối thiết lập hai kết hợp bảo mật IPsec. Thực hiện hai sự kết hợp này cho phép các đầu cuối P-CSCF dùng UDP để nhận các phản hồi cho một yêu cầu (số hiệu port nằm trong mà đầu Via của yêu cầu) trên một port khác với port được dùng cho việc gửi yêu cầu (do có hai port nên cần hai sự kết hợp bảo mật). Hoặc theo cách khác, P-CSCF dùng cùng một kết nối TCP để gửi và nhận yêu cầu và phản hồi. Trong cả hai trường hợp, sự kết hợp bảo mật được thiết lập từ port client-protected của đầu cuối đến port server-protected của P-CSCF và ngược lại, sự kết hợp bảo mật này sẽ hỗ trợ bảo mật cho lưu lượng theo cả hai hướng.
Protected Client Port Protected Server Port Protected Server Port Protected Client Port Requests Requests Responses Responses P-CSCF
Protected Client Port Protected Server Port Protected Server Port Protected Client Port Requests Requests Responses Responses P-CSCF Hình 2.9. Sự kết hợp bảo mật dùng trên TCP [3]
Sau khi yêu cầu sơ cấp lên tới S-CSCF để thực hiện việc nhận thực, S-CSCF sẽ gửi lại phản hồi 401 Unauthorized (chứa các tham số cần thiết cho sự kiểm tra nhận thực như IK, CK, AUTN và RAND) lại phía UE.
2.2.2 Bảo mật mạng
Bảo mật mạng được dùng cho việc bảo mật lưu lượng giữa các miền mạng khác nhau. Tất cả lưu lượng tới hoặc đi khỏi miền bảo mật đều phải qua cổng bảo mật SEG (Security Gateway). Lưu lượng từ một miền mạng đến một miền mạng khác phải qua hai SEG (hình 2.10). SEG SEG Interdomain traffic Sercurity Domain 1 Sercurity Domain 2
Hình 2.10. Lƣu lƣợng qua hai cổng bảo mật [3]
Lưu lượng giữa các SEG được bảo vệ bằng việc dùng IPsec ESP (Encapsulated Security Payload định nghĩa trong RFC 2406 ) hoạt động ở chế độ ngầm. Sự kết hợp bảo mật giữa các SEG được thiết lập và được duy trì nhờ dùng IKE (Internet Key Exchange định nghĩa trong RFC 2409 .
Có hai loại giao diện giữa các SEG: giao diện Za giữa các SEG thực hiện truyền lưu lượng giữa các miền mạng khác nhau, và Zb giữa các SEG nội miền (hình 2.11).
SEG SEG Za Zb Zb Zb Zb Zb Zb CSCF CSCF CSCF CSCF
2.2.3 Một số khái niệm chi tiết liên quan đến bảo mật
Khi Server nhận được một yêu cầu từ Client, nó sẽ mời Client cung cấp các khả năng của Client trong miền mạng (Client sẽ cung cấp tên và các chứng thực rằng Client cũng đã biết Share Secret - như password chẳng hạn). Chính vì thế cần mật mã các thông tin này khi truyền giữa Client và Server. Client dùng digest có thể chứng thực các thông tin bí mật đó mà không cần gửi qua mạng.
TLS - bảo mật lớp truyền tải
TLS (Transport Layer Security, định nghĩa trong RFC 2246 ) dựa trên SSL (Secure Socket Layer). SSL được thiết kế cho việc bảo vệ thông tin web và được triển khai trong hầu hết các trình duyệt Internet. TLS tổng quát hơn SSL, nó có thể được dùng để bảo vệ bất cứ loại kết nối nào. Vì thế TLS được dùng để bảo vệ lưu lượng SIP.
TLS có hai lớp: lớp bắt tay (TLS handshake) và lớp bản ghi (TLS record). TLS handshake thực hiện nhận thực các thực thể ngang hàng, nó dùng các khóa công cộng và các chứng chỉ (Certifỉcate - hay khoá để hiểu TLS và S/MINE), thuật toán để tạo mã bảo mật truyền dữ liệu, hay còn gọi là khoá bảo mật. TLS record thực hiện mã hóa dữ liệu. Nó dùng thuật toán mã hóa đối xứng có khóa được tạo từ giá trị được lớp handshake cung cấp.
Hình 2.12. Thiết lập kết nối TLS [9]
S/MINE
Khi UE muốn chuyển các thông tin mà proxy không thể truy nhập (ví dụ như nội dung của luồng audio hay video giữa hai user), thì SIP cần dùng giải pháp bảo mật end-to-end hay dùng S/MINE (Secure/Multipurpose Internet Mail Extension). Thường thì thân của bản tin sẽ được dùng với S/MINE, đôi khi nó cũng được dùng để mật mã hoặc mã hoá các mào đầu có