4.1.2.1 Server
Là một chương trình ứng dụng chấp nhận các bản tin yêu cầu từ Client để phục vụ các yêu cầu này và gửi trả các đáp ứng cho các yêu cầu đó. Ta có các loại server sau:
Proxy Server: là phần mềm trung gian, hoạt động như là Server, vừa là Client cho các mục đích tạo các yêu cầu thay mặt cho các Client khác. Các yêu cầu được xử lý bên trong hoặc chuyển chúng đến Server khác có chức năng định tuyến. Trong IMS, khối P-CSCF đóng vai trò là Proxy Server nhằm chuyển các yêu cầu của UE đến thực thể thích hợp.
Redirect Server: là một Server chấp nhận một yêu cầu SIP, ánh xạ địa chỉ trong yêu cầu thành địa chỉ mới và trả lại địa chỉ này trở lại Proxy Server.
Registrar Server: là máy chủ chấp nhận yêu cầu đăng kí. Một Registrar Server được xếp đặt với một Proxy Server hoặc một Server gởi lại và có thể đưa ra các dịch vụ định vị. Registrar Server dùng để đăng kí các đối tượng SIP trong miền SIP và cập nhật lại vị trí hiện tại của chúng.
Location Server: Cung cấp chức năng phân giải tên cho SIP Proxy hoặc Redirect Server. Sever này có thuật toán để phân giải tên. Các cơ chế này bao gồm một database của nhà đăng ký hoặc truy nhập đến những công cụ phân giải tên được sử dụng phổ biến như whois, LDAP, hoặc các hệ thống hoạt động độc lập khác. Registrar server có thể là một thành phần con của location server; registrar server chịu trách nhiệm một phần trong việc populating database mà được liên kết với Location Server
Trong IMS, HSS đóng vai trò như một Registrar Server chứa cơ sở dữ liệu về thuê bao và dịch vụ thuê bao đã đăng ký. S-CSCF chính là Location Server, đảm nhiệm phụ vụ cho một nhóm thuê bao trong mạng đó hoặc chuyển vùng sang mạng IMS. I-CSCF thực hiện chức năng như một Redirect Server, giao tiếp với S-CSCF của mạng khác khi UE sử dụng dịch vụ liên mạng.
Hình 4.1: Cấu trúc SIP 4.1.2.2 Client
Client trong giao thức SIP chính là UE, là các thiết bị mà người dùng sử dụng để khởi tạo yêu cầu SIP đến các Server. Thiết bị này có thể là Hardphone hay Softphone. Hardphone là các thiết bị phần cứng hổ trợ chuẩn SIP như điện thoại IP. Softphone là phần mềm hổ trợ chuẩn SIP như Express Talk, Sidefisk,… hay hổ trợ cả IMS như: Mercuro IMS Client, UCT Client, OpenIC_Lite,. . .
4.1.3 Bản tin SIP
SIP sử dụng các bản tin để khởi tạo, hiệu chỉnh và kết thúc phiên giữa các người dùng.
Bảng 4.1: Bản tin yêu cầu SIP Bản tin Ý nghĩa
INVITE Khởi tạo một phiên
ACK Khẳng định rằng client đã nhận được bản tin
đáp ứng cho bản tin INVITE
BYE Yêu cầu kết thúc phiên
CANCEL Yêu cầu kết thúc phiên
Register Đầu cuối SIP đăng ký với Register server
OPTIONS Đầu cuối SIP đăng ký với Register server
INFO Sử dụng để tải các thông tin
Bảng 4.2: Bản tin đáp ứng SIP Bản tin Ý nghĩa
1xx Các bản tin chung
2xx Thành công
3xx Chuyển địa chỉ
4xx Yêu cầu không được đáp ứng
5xx Sự cố Server
4.2 Giao thức Diameter
4.2.1 Tổng quan về giao thức Diameter
Ban đầu, con người muốn truy cập vào internet đến một Server cụ thể nào đó, người đó phải cung cấp thông tin về user name và password. Trong hầu hết các trường hợp, thông tin về user name và password không được lưu ở máy chủ đáp ứng truy cập mà được lưu ở một nơi khác, có thể là Lightweight Directory Access Protocol. Do đó nảy sinh vấn đề cần một giao thức truyền thông đáng tin cậy để trao đổi thông tin giữa máy chủ truy cập và máy lưu thông tin về user name và password. Vì thế, vào 1995 RADIUS ra đời, được dùng để chứng thực, quản lý quyền truy cập dịch vụ, thông tin tài khoản người dùng. Khi công nghệ di động ngày càng phát triển thì RADIUS không đáp ứng được yêu cầu về QoS và không hỗ trợ chuyển vùng. Điều này là một trở ngại lớn trong sự phát triển dịch vụ. Một yêu cầu đặt ra là tìm ra một công nghệ mới không chỉ đáp ứng được tính năng của RADIUS mà còn khắc phục được những nhược điểm của giao thức này. Đến 1996, IETF chuẩn hóa Diameter trong RFC 3588. Giao thức này thỏa mãn các yêu cầu đặt ra ở trên.
Giao thức Diameter chia ra 2 phần: Diameter Base Protocol và Diameter Application. Diameter Base Protocol cần thiết cho việc phân phối các đơn vị dữ liệu, khả năng thương lượng, kiểm soát lỗi và khả năng mở rộng. Diameter Application định nghĩa những ứng dụng dữ liệu riêng. Tại thời điểm này, ngoài ứng dụng chuẩn trong RFC3588, một số ứng dụng đã được định nghĩa như: Mobile IP, NASREQ, EAP, Diameter điều khiển tính phí và ứng dụng Diameter trong giao thức SIP,… Diameter là giao thức truyền thông hoạt động trên giao diện Sh giữa HSS, AS, S-CSCF.
Hình 4.2: Giao thức Diameter 4.2.2 Cấu trúc giao thức Diameter (adsbygoogle = window.adsbygoogle || []).push({});
Trong Diameter có 3 thành phần chính là Server, Client và Agent. Client là một thiết bị ở biên, thực hiện các truy vấn và sử dụng dịch vụ. Một Diameter Agent thực hiện chức năng như một Proxy, Relay, Redirect Agent va dịch các bản tin. Diameter Server quản lý các yêu cầu về AAA cho một hệ thống.
4.2.2.1 Diameter Relay Agent
Diameter Relay Agent là một thực thể chấp nhận các yêu cầu và định tuyến các bản tin đến một thực thể khác dựa trên thông tin tìm được trong bản tin như tên miền đích đến của bản tin. Thông tin định tuyến này được thực hiện dựa vào bảng định tuyến được lưu trữ tại các nút mạng. Bảng định tuyến này chứa các trường sau: tên miền, mã ứng dụng, hoạt động cục bộ, nhận dạng Server, cấu hình tĩnh hoăc động, thời gian hết hạn.
Mã ứng dụng được dùng như trường quan trọng thứ 2 để tìm kiếm một entry. Trường hoạt động cục bộ chứa một trong bốn giá trị: Local, Relay, Proxy, Redirect. Dựa vào trường này mà Diamter Relay sẽ biết xử lý gói tin hay chuyển tiếp gói tin. Trường nhận dạng Server để xác định nút mạng kế tiếp cần đi đến. Cấu hình tĩnh hay động cho biết
entry này được cấu hình tĩnh hoặc tự động tìm ra nút kết tiếp. Nếu là cấu hình động thì có thời gian hết hạn mà entry đó phải được cập nhật lại.
Tổng hợp những yêu cầu đến các miền khác nhau và phân bố gói tin đến đích thích hợp giúp giảm nhẹ cấu hình máy chủ truy cập cũng như thuận tiện cho việc thay thế, thêm hoặc bỏ máy chủ truy cập.
Diameter Relay Agent thay đổi bản tin bằng cách chèn vào hoặc bỏ các thông tin định tuyến mà không thay đổi bất kì phần nào khác của bản tin. Relay Agent sẽ không duy trì trạng thái phiên mà chỉ duy trì trạng thái giao dịch để thực hiện chức năng Accouting.
4.2.2.2 Diameter Proxy Agent
Hình4.3 Diameter Proxy Agent định tuyến các bản tin dựa vào bảng định tuyến
Giống như Relay, Proxy Agent định tuyến các bản tin Diameter sử dụng bảng định tuyến. Tuy nhiên, giữa hai thành phần có sự khác nhau về cách thay đổi bản tin để thực hiện chính sách
4.2.2.3 Diameter Redirect Agent
Hình 4.4 Diameter Redirect Agent
Diameter Reditect Agent thực hiện việc đinh tuyến các bản tin sang tên miền khác. Nó cũng sử dụng bảng định tuyến để xác định chặng tiếp theo của đường đi đến đích đã được yêu cầu. Thay tự vì định tuyến những yêu cầu, Redirect Agent sẽ đáp ứng lại địa chỉ của chặng kết tiếp để Proxy Agent định tuyến.
4.2.2.4 Diameter Translation Agent
Hình 4.5 Diameter Translation Agent
Diameter Translation Agent là thành phần thực hiện việc chuyển đổi dịch vụ giữa Diameter và một giao thức thực hiện chức năng AAA khác. Translation Agent sử dụng để tương thích với các dịch vụ trên cơ sở hạ tầng mạng sẵn có phổ biến như RADIUS, TACACS,….
4.2.3 Bản tin
Bản tin Diameter chứa một header và một số cặp giá trị thuộc tính AVP. Header gồm nhiều trường với dữ liệu dạng nhị phân giống header của giao thức IP.
Hình 4.6 Cấu trúc bản tin trong giao thức Diameter 4.2.3.1 Cấu trúc Diameter header
Version: được thiết lập bằng 1 ứng với phiên bản hiện nay của giao thức Diameter là 1.
Command Flags: trường này dài 8 bit. Có dạng RPETrrrr, có ý nghĩa như sau:
R (request): nếu bằng 1, đây là bản tin yêu cầu. Nếu bằng 0 là bản tin đáp ứng.
P (proxiable): nếu bằng 1, bản tin có thể chuyển tiếp bởi Proxy, Relay hoặc Redirect. Nếu bằng 0 thì bản tin sẽ được xử lý tại nút
E (error): Nếu bằng 1, bản tin đáp ứng chứa lỗi giao thức, và bản tin sẽ không phù hợp với mô tả ABNF. Nếu bằng 0 trong bản tin yêu cầu và không lỗi.
T (potentially re-transmitted masage): Bit này bằng 1 khi liên kết bị đứt, bản tin yêu cầu bị trùng hoặc không có trả lời từ Server
r: dự trữ, luôn bằng 0
Command Code: trường này dài 24 bit, được quản lý bởi IANA, giá trị từ 0- 24 dùng riêng cho RADIUS, 16777214 và16777215 dùng thí nghiệm, các số còn lại dùng trong giao thứcDIAMETER.
Application-ID: dài 32 bit, dùng để xác định tên ứng dụng do IANA quản lý. Ứng dụng có thể là một ứng dụng dành cho việc chứng thực, một ứng dụng quản lý tài khoản người dùng hoặc một ứng dụng cụ thể của một nhà sản xuất nào đó. Nó là một dáy số từ 0x00000001 đến 0x00ffffff. Sau đây là một số Application-ID:
Bản tin Diameter chung 0
NASREQ 1 (adsbygoogle = window.adsbygoogle || []).push({});
Mobile-IP 2
Chức năng Accounting trong Diameter 3
Application ID trong header phải giống với nội dung chứa trong AVP.
Hop-by-Hop Identifier: dài 32 bit, giúp phù hợp giữa bản tin yêu cầu và đáp ứng trong 1 kết nối trong 1 thời gian
End-to-end Identifier: xác định bản tin bị trùng
4.2.3.2 Cấu trúc AVP
AVP chứa thông tin chứng thực, ủy quyền, và thông tin về tài khoản người dùng để định tuyến, bảo mật, thông tin cấu hình có liên quan đến yêu cầu và đáp ứng bản tin. Mỗi AVP chứa AVP header và AVP data.
Hình 4.8 Cấu trúc AVP
4.2.3.2.1 AVP Header
Trường AVP Code: dài 32 bit, được quản lý bởi IANA, dùng để xác nhận các
thuộc tính với trường Vendor-ID. Giá trị từ 0-255 dùng để tương thích vói RADIUS, các giá trị còn lại dùng trong DIAMETER
Trường AVP Flag dài 8 bit, có dạng VMPrrrrr, mỗi bit có ý nghĩa như sau:
Bit V (vendor -ID): nếu bằng một thì thông tin sẽ được đề cập trong trường Vendor-ID, ngược lại trường Vendor-ID rỗng.
Bit M (Mandatory): UE sẽ không nhận bản tin này nếu bit này bằng 0.
Bit P (Protect): nếu bằng 1 thì bản tin được yêu cầu mã hóa end-to-end.
Trường AVP length: chiều dài AVP data
4.2.3.2.2 AVP Data
Trường AVP data có thể là rỗng hoặc nhiều octet chứa thông tin về thuộc tính cụ thể.Định dạng và chiều dài của trường này được xác định bởi trường AVP Code và AVP Length. Định dạng của trường này là một trong những dạng dữ liệu chuẩn sau đây: OctetString,Interger32,Interger64,Unsigned32,Unsigned64,Float32,Float64,Grouped...Để tìm hiểu kỹ về các dạng dữ liệu này, người xem có thể tham khảo [RFC 3588]. Trong trường hợp cần có một dạng dữ liệu cơ bản mới cho AVP Data thì một phiên bản RFC mới hơn phải được tạo ra.
Ngoài việc sử dụng các dạng dữ liệu cơ bản, trường này còn có thể sử dụng các định dạng dữ liệu khác nhau theo ứng dụng. Có một số dạng dữ liệu theo ứng dụng như sau:
Address: dạng dữ liệu này được tạo ra từ dạng OctetString ( dạng dữ liệu cơ bản). Nó có thể là dạng địa chỉ 32 bit (Ipv4) hoặc 128 bit (IPv6).
Time: dạng dữ liệu này được tạo ra từ OctetString. Chuỗi (string) phải dài bốn octet. Dạng dữ liệu này giống định dạng của SNTP [RFC 2030]
Diameter Identity: dạng dữ liệu này được tạo ra từ OctetString, dùng để xác định sự duy nhất của một nút trong mạng, tránh trường hợp có nhiều đường kết nối đến một nút dẫn đến trình trạng bị lặp trong định tuyến. Nội dung chuỗi dữ liệu trong kiểu này là FQDN của một nút Diameter.
Ngoài ra còn có các dạng dữ liệu khác như: UTF8String, DiameterURI, Enumerated, IPFilterRule, QoSFilterRule, … [RFC 3588]
4.2.4 Bảo mật trong bản tin Diameter
Client trong giao thức Diameter phải hổ trợ chuẩn IPSec và có thể hổ trợ TLS.Server phải hổ trợ cả 2 chuẩn trên.Để bảo mật, khuyến nghị rằng nên sử dụng IPSec ở các nút trong cùng một miền như giữa Client và Proxy và sử dụng TSL để bảo mật khi có giao dịch
giữa các miền với nhau. Khi sử dụng TSL, hai phía phải thương lượng một Cipher key theo một trong các thuật toán sau:
RC4_128_MD5
RC4_128_SHA
3DES_EDE_CBC_SHA
AES_128_CBC_SHA (adsbygoogle = window.adsbygoogle || []).push({});
4.2.5 Khả năng kiểm soát lỗi của giao thức Diameter
Lỗi trong giao thức Diameter chia thành 2 loại: lỗi giao thức và lỗi ứng dụng
Lỗi giao thức
Xảy ra ở cấp độ giao thức cơ bản như lỗi định tuyến. Khi xuất hiện lỗi, bit E trong trường Command Flag của Diameter Header trong bản tin đáp ứng sẽ được bật lên 1 và gởi trở lại theo đường đến.
Hình 4.9: Lỗi giao thức trong Diameter
Lỗi ứng dụng
Xảy ra ở các ứng dụng của Diameter như chứng thực User, mất gói AVP. Khi xuất hiện lỗi, bit R trong Command Flag trong bản tin đáp ứng được bật lên 1 và gởi lại cho User khởi tạo không thông qua Agent
Hình 4.10: Lỗi ứng dụng trong giao thức Diameter
Các bản tin đáp ứng lại trong trường hợp có lỗi:
Bảng 4.3: Bản tin đáp ứng trong trường hợp có lỗi xảy ra
4.3 COPS Giao thức COPS
4.3.1 Tổng quan về giao thức COPS
COPS là giao thức được IETF chuẩn hóa nhằm thực hiện việc quản lý, cấu hình và áp đặt chính sách. Giao thức này hoạt động theo mô hình Client-Server. Nó định nghĩa một giao thức yêu cầu và đáp ứng một cách đơn giản trong việc trao đổi thông tin chính sách và
được xem là Client và server là điểm quyết định chính sách PDP. Và một thành phần đặc biệt là điểm quyết định chính sách cục bộ LPDP, nó thay thế cho PDP trong việc liên lạc với PEP khi PDP không được tìm thấy. COPS điều khiển chính sách theo 2 mô hình chính:
Outsourcing
PEP chỉ định một PDP bên ngoài chịu trách nhiệm xử lý những sự kiện gởi ra từ PEP. Mô hình này cho thấy sự tương quan one-to-one giữa những sự kiện ở PEP và những quyết định từ một PDP.
Configuration
Không giống như mô hình trước, là không có sự ánh xạ trực tiếp những sự kiện tại PEP và những quyết định từ PDP. PDP có thể cấu hình những sự kiện bên ngoài được khởi tạo bởi một PEP bất kỳ và sự kiện gởi từ PEP có thể được xử lý bởi PDP cùng khối với nó hoặc PDP thuộc khối khác. Xét về mặt thời gian thì mô hình này linh động hơn mô hình outsourcing.
Cops sử dụng phương thức truyền TCP để truyền những bản tin đáng tin cậy giữa PEP và PDP. Không giống như giao thức client - server khác, cặp bản tin yêu cầu - đáp ứng này phải phù hợp với cặp bản tin yêu cầu - đáp ứng khác. Ở đây, server có thể áp áp đặt chính sách cho client và xóa những chính sách trên client nếu chính sách đó không còn phù hợp nữa. PEP khởi tạo kết nối TCP đến PDP, PEP gởi yêu cầu và nhận những quyết định chính sách từ PDP và sự liên lạc giữa PEP và PDP là sự trao đổi yêu cầu, đáp ứng. Tuy nhiên PDP hoặc PEP có thể gởi đi những bản tin độc lập, ví dụ như PDP gởi những quyết định tới PEP bắt buộc PEP thay đổi những chính sách được PDP chấp nhận trước đó (không phải bản tin đáp ứng cho những yêu cầu của PEP) và PEP có thể gởi những bản tin báo cáo về trạng thái cho PDP. Sự mở rộng có thể được mô tả trong phần định dạng bản tin và những phần tử mang dữ liệu về chính sách không cần yêu cầu bất kỳ thay đổi nào trong giao thức.
COPS được sử dụng trong liên lạc giữa khối PDF và GGSN, tạo sự kết nối giữa mạng