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
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: (adsbygoogle = window.adsbygoogle || []).push({});
Bản tin Diameter chung 0
NASREQ 1
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 (adsbygoogle = window.adsbygoogle || []).push({});
3DES_EDE_CBC_SHA
AES_128_CBC_SHA
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 IMS và mạng GPRS nhằm cung cấp mức độ bảo mật các bản tin cho việc xác thực, bảo vệ toàn vẹn bản tin. COPS cũng có thể tái sử dụng giao thức về bảo mật như IPSEC hoặc TLS để xác thực và bảo vệ kênh truyền giữa PEP và PDP.
Hình 4.11: Mô hình COPS 4.3.2 Chức năng chính của COPS
Giao thức này giao việc cho Client hỗ trợ cho mô hình Client/Server. Trong đó Client sẽ gởi những bản tin: yêu cầu, cập nhật, và xóa tới PDP và PDP gởi trả những quyết định cho PEP.
COPS sử dụng phương thức TCP để trao đổi bản tin giữa Server và Client nên ta không cần bổ sung thêm chức năng hỗ trợ việc liên lạc có đảm bảo giữa Server và Clients.
COPS thực hiện việc quản lý, cấu hình, và thực thi các chính sách
COPS cung cấp mức độ bảo mật các bản tin cho việc xác thực, phát lại bảo vệ, và toàn vẹn bản tin.COPS cũng có thể tái sử dụng giao thức về bảo mật như IPSEC hoặc TLS để xác thực và bảo vệ kênh truyền giữa PEP và PDP.
COPS cho phép Server áp dụng chính sách cho Client hoặc xóa chính sách đang thực thi trên Client nếu nó không còn được sử dụng nữa.
4.3.2.1 Bản tin COPS
Bản tin của giao thức COPS gồm COPS Header và Object format (adsbygoogle = window.adsbygoogle || []).push({});
4.3.2.1.1 COPS Header
Hình 4.12: COPS header
Version (4bits): chỉ phiên bản của giao thức COPS đang được dùng, hiện nay đang sử dụng COPS version 1
Flags (4bits): mặc định là 0, cờ flag đặt lên 1 khi bản tin gởi đi là bản tin DEC, khi đó PDP gởi bản tin DEC đáp ứng lại yêu cầu của bản tin REQ do PEP gởi ra.
Op Code (8 bits): cho biết hoạt động của COPS.
Bảng 4.4: Các loại Op code trong COPS header Giá trị Loại Nơi chốn Tên Mô tả
1 REQ PEP→PDP Request Yêu cầu quyết định từ PDP và
thiết lập một client handle nhằm xác định tình trạng phù hợp cho PEP
2 DEC PDP→PEP Decision Trả lại một hoặc nhiều quyết định
(đáp ứng) cho một yêu cầu
3 RPT PEP→PDP Report state Báo cáo lại cho PDP biết là PEP
đã nhận được đáp ứng của PEP hay chưa và thông báo sự thay đổi trạng thái của PEP
4 DRQ PEP→PDP Delete request state
Thông báo cho PDP biết là
5 SSQ PDP→PEP Synchronize
state request
PDP gởi cho PEP để đồng bộ dữ liệu
6 OPN PEP→PDP Client-Open
7 CAT PDP→PEP Client-
Accept
8 CC PEP→PDP
PDP→PEP
Client-Close Cho biết phần tử Client-type không được hỗ trợ
9 KA PEP→PDP
PDP→PEP
Keep-Alive Kiểm tra sự tồn tại của PDP/PEP
10 SSC PEP→PDP Synchronize
complete
Thông báo sự đồng bộ thành công
Client-type (16 bits): cho biết chính sách áp dụng cho Client và xác định những thực thể liên quan. 16 bit s có giá trị trong khoảng 0x8000 - 0xFFFF. Đối với bản tin KA thì Client-type phải đặt là 0. (adsbygoogle = window.adsbygoogle || []).push({});
Message Length (32 bits): bao gồm header chuẩn và phần tử rút gọn và độ dài chỉ trong 4bytes.
Hình 4.13: Object format của bản tin COPS
Length: chiều dài của Object format
C-num (8 bits): cho biết lớp thông tin chứa đựng trong object
Bảng 4.5: Trường C-Num trong Object format của bản tin COPS