1.10 Bảo Mật Truy Cậ p IPsec Sas
1.10.5 Thiết Lập Cổng Và Định Tuyến
XVIII.Cần đặc biệt chú ý khi nói đến việc sử dụng các cổng SA, vì chúng ảnh hưởng rất
nhiều đến việc định tuyến giữa P-CSCF và UE. Như trong Hình 11.6, XIX. UE của Tobias:
• sẽ gửi tất cả các yêu cầu từ cổng khách hàng được bảo vệ của nó (2468);
• mong đợi tất cả các phản hồi sẽ được nhận trên cổng máy chủ được bảo vệ của nó (1357);
• mong đợi tất cả các yêu cầu sẽ được nhận tại cổng máy chủ được bảo vệ của nó (1357);
• sẽ gửi tất cả các phản hồi cho các yêu cầu nhận được từ cổng khách hàng được bảo vệ của nó (2468).
XX. Mặt khác, P-CSCF:
• sẽ gửi tất cả các yêu cầu tới UE từ cổng khách hàng được bảo vệ của nó (8642); • mong đợi nhận được tất cả các phản hồi từ UE tại cổng máy chủ được bảo vệ của nó (7531);
1mong đợi nhận được tất cả các yêu cầu từ UE tại cổng máy chủ được bảo vệ của nó
(7531); và
•sẽ gửi tất cả các phản hồi tới UE từ cổng máy khách được bảo vệ của nó
(8642).
Để đảm bảo rằng tất cả các yêu cầu đều được gửi qua IPsec SAs:
•UE sẽ đặt cổng máy chủ được bảo vệ như một phần của địa chỉ:
◦trong tiêu đề Liên hệ của mọi yêu cầu (bao gồm tất cả các yêu cầu
REGISTER)
◦trong tiêu đề Qua của mọi yêu cầu, bên cạnh REGISTER ban đầu.
•UE sẽ đặt cổng máy chủ được bảo vệ của P-CSCF như một phần của proxy
gửi đi
(tức là P-CSCF) địa chỉ trong tiêu đề Lộ trình của mọi yêu cầu ban đầu mà nó gửi.
•P-CSCF sẽ đặt cổng máy chủ được bảo vệ như một phần của địa chỉ:
◦ trong tiêu đề Record-Route của mọi phản hồi mang P-CSCF’s
XXI. Mục nhập Record-Route về phía UE (để cài đặt chi tiết số cổng trong XXII. Tiêu đề Record-Route xem Phần 12.3.4.3).
XXIII.1.10.5.1:Thiết lập cổng trong khi đăng ký
XXIV. Ví dụ: UE của Tobias đăng ký ban đầu với thông tin sau: XXV. REGISTER sip:home1.fr SIP/2.0
XXVI.Via: sip:[5555:1:2:3:4]:1357;branch=0uetb XXVII. Route: <sip:[5555::a:b:c:d];lr>
XXVIII. Security-Client: digest, IPsec-3gpp; alg=hmac-sha-1-96 XXIX.;spi-c=23456789 ;spi-s=12345678
XXX. ;port-c=2468; port-s=1357
XXXI.Contact: "Mobile Phone - Tobias" sip:[5555::1:2:3:4]:1357
XXXII. Điều này có nghĩa là UE: • Sẽ thiết lập IPsec SA với:
◦ cổng 2468 làm cổng máy khách được bảo vệ (thông số cổng-c của Máy khách-Bảo mật tiêu đề);
◦ cổng 1357 làm cổng máy chủ được bảo vệ (tham số cổng của Máy khách bảo mật đầu trang).
• Mong đợi tất cả các yêu cầu đến được chuyển đến cổng máy chủ được bảo vệ của nó
(giá trị cổng trong tiêu đề Liên hệ);
• Sẽ gửi yêu cầu REGISTER ban đầu này tới cổng 5060 không được bảo vệ của P CSCF, vì không có giá trị cổng nào được đưa ra trong tiêu đề Tuyến đường;
• Sẽ chờ tất cả các phản hồi cho yêu cầu REGISTER ban đầu này trên cổng 5060 không được bảo vệ, như không có giá trị cổng nào được đưa ra trong tiêu đề Via. Phản hồi 401 (Không được phép) mà UE nhận được sau đó sẽ có dạng như thế này: SIP/2.0 401 Unauthorized
XXXIII. Via: sip:[5555:1:2:3:4]:1357;branch=0uetb
XXXIV. Security-Server: tls ;q=0.2, IPsec-3gpp; q=0.1 ;alg=hmac-sha-1-96 ;spi- XXXV. 0=98765432 ;spi-s=87654321 ;port-c=8642 ;port-s=7531
XXXVI. Điều này có nghĩa là P-CSCF sẽ thiết lập IPsec SA với:
• cổng 8642 làm cổng máy khách được bảo vệ (tham số cổng-c của tiêu đề Máy chủ- Bảo mật)
• cổng 7531 làm cổng máy chủ được bảo vệ (tham số cổng của tiêu đề Máy chủ-Bảo mật).
XXXVII. Sau cuộc trao đổi này, UE và P-CSCF sẽ thiết lập bộ SA tạm thời và UE sau đó sẽ gửi
yêu cầu REGISTER thứ hai đã được bảo vệ, sau đó sẽ trông giống như: XXXVIII. REGISTER sip:home1.fr SIP/2.0
XXXIX. Via: sip:[5555:1:2:3:4]:1357;branch=1uetb XL. Route: <sip:[5555::a:b:c:d]:7531;lr>
XLI. Contact: "Mobile Phone - Tobias" sip:[5555::1:2:3:4]:1357
XLII. Lưu ý rằng các tiêu đề Security-Client và Security-Verify cũng được bao gồm trong
yêu cầu này (xem Phần 1.8), nhưng vì chúng không còn ảnh hưởng đến việc thiết lập SA và định tuyến, chúng không được hiển thị ở đây. Điều này có nghĩa là UE: mong đợi tất cả các yêu cầu ban đầu đến sẽ được chuyển đến cổng máy chủ được bảo vệ của nó (giá trị cổng trong tiêu đề Liên hệ);
• gửi yêu cầu REGISTER này đã qua IPsec SA tạm thời (tức là cho người được bảo vệ
cổng máy chủ của P-CSCF - giá trị cổng trong tiêu đề Tuyến đường); và
• Mong đợi tất cả các phản hồi cho yêu cầu REGISTER này sẽ được gửi qua IPsec SA
tạm thời (nghĩa là trên cổng máy chủ được bảo vệ 1357 - giá trị cổng trong tiêu đề Via).
XLIII. 1.10.5.2:Thiết lập cổng trong khi xác thực lại
XLIV. Như đã nói trước đây, mỗi lần xác thực lại sẽ tạo ra một cặp IPsec SA mới. Khi nào
trao đổi chỉ mục tham số bảo mật và số cổng được bảo vệ cho tập hợp mới của SA theo Thỏa thuận Cơ chế An ninh SIP, chỉ P-CSCF và UE thay đổi các cổng máy khách được bảo vệ của họ:
• UE nhận được yêu cầu và phản hồi cho cả hai tập hợp SA thông qua máy chủ được bảo vệ của nó cổng (us1);
• P-CSCF nhận các yêu cầu và phản hồi cho cả hai nhóm SA thông qua máy chủ được bảo vệ của nó cổng (ps1);
• UE sử dụng một cổng máy khách được bảo vệ mới (uc2) để gửi các yêu cầu và phản hồi đối với P-CSCF trên tập hợp các SA mới; và
• P-CSCF cũng sử dụng một cổng máy khách được bảo vệ mới (pc2) để gửi các yêu cầu và phản hồi của UE đối với tập hợp các SA mới. Điều này là do thực tế là hai bộ SA không được sử dụng các tham số cổng giống nhau. Hơn nữa, nếu các cổng máy chủ được bảo vệ thay đổi, điều này sẽ gây ra các vấn đề lớn và có nghĩa là:
• UE sẽ cần thực hiện đăng ký lại, vì địa chỉ liên hệ đã đăng ký của nó bao gồm cổng máy chủ được bảo vệ;
• UE sẽ cần gửi lại INVITE trên tất cả các phiên đã thiết lập, vì thông tin liên hệ của nó được gửi đến đầu cuối từ xa bao gồm cổng máy chủ được bảo vệ;
• P-CSCF sẽ nhận từ UE tất cả các yêu cầu tiếp theo đối với mọi hộp thoại lished đã được thiết lập (bao gồm tất cả các đăng ký của UE) trên P-CSCF cũ, được bảo vệ cổng máy chủ, vì trong SIP không có khả năng thay đổi thông tin tuyến đường cho một hộp thoại đã được thiết lập. Danh sách này không đầy đủ, nhưng nó cho thấy rằng việc thay đổi cổng máy chủ được bảo vệ sẽ gây ra rất nhiều vấn đề cho định tuyến SIP. Do đó, điều cốt yếu là giá trị này không đã thay đổi miễn là người dùng vẫn đăng ký. XLV. 1.10.5.3: Cài đặt cổng cho các yêu cầu SIP ngoài REGISTER
XLVI. Việc thiết lập các cổng được bảo vệ trong các yêu cầu không REGISTER được mô tả
chi tiết hơn trong Phần 3.7.
XLVII.--- Requests and Responses from the UE w
uc1 --- — ► ps1
I
XLVIII. us 1 Requests and Responses to the UEc 1
XLIX. Định tuyến yêu cầu và phản hồi giữa UE và P-CSCF qua UDP
L. Requests from the UE
LI. uc1 ps1
LII. Responses to the UE
LIII. Requests to the UE
LIV. us1 pc1
Hình 1.8 Định tuyến yêu cầu và phản hồi giữa UE và P-CSCF qua TCP 1.10.5.4: Sử dụng các cổng với UDP và TCP
Các phần trước đã cho thấy cách các yêu cầu và phản hồi được chuyển qua một hoặc nhiều tập hợp các SA. Trong ví dụ đã chọn, chỉ UDP được sử dụng làm giao thức truyền tải. Đối với TCP, tuy nhiên, có một chút khác biệt trong các thủ tục này. Khi một yêu cầu được gửi qua UDP (Hình 11.8), tiêu đề Via cho biết địa chỉ IP và số cổng mà tất cả các phản hồi liên quan sẽ được chuyển đến. Khi TCP được sử dụng để gửi yêu cầu (Hình 11.9) thông tin trong tiêu đề Via bị ghi đè và phản hồi được chuyển trở lại cùng một địa chỉ và cổng mà yêu cầu đã được nhận. Điều này rút ra chú ý đến bản chất của TCP như một giao thức truyền tải hướng kết nối. Bằng cách áp dụng quy tắc này được đảm bảo rằng không cần mở thêm kết nối TCP nào để gửi phản hồi cho một yêu cầu đã được nhận qua TCP. Điều này gây ra việc định tuyến các bản tin SIP giữa P-CSCF và UE để hoạt động khác nhau. UE sẽ đặt máy chủ được bảo vệ của nó cổng (us1) trong tiêu đề Via của mọi yêu cầu mà nó gửi đi, bất kể UDP có hoặc TCP được sử dụng. Tất cả các yêu cầu sẽ bắt nguồn từ cổng máy khách được bảo vệ của UE (uc1). Trong trường hợp của UDP, các phản hồi cho một yêu cầu như vậy sẽ được gửi đến UE được bảo vệ cổng máy chủ (us1), như được chỉ ra trong tiêu đề Qua. Trong trường hợp TCP, các phản hồi cho một yêu cầu như vậy sẽ được gửi đến UE được bảo vệ cổng máy khách (uc1), vì yêu cầu bắt nguồn từ đó. Điều này cũng đúng trong cái khác (nghĩa là đối với các yêu cầu được gửi từ P-CSCF tới UE và phản hồi của họ). 1.10.6: Các tiêu chuẩn liên quan
Các thông số kỹ thuật liên quan đến Mục 1.10 là: 3GPP TS 33.102 Kiến trúc bảo mật.
3GPP TS 33.203 Bảo mật truy cập cho các
dịch vụ dựa trên IP.Bảo mật miền mạng 3GPP TS 33.210 (NDS) Bảo mật lớp mạng IP.
RFC2401 Giao thức Internet.
RFC2403 Việc sử dụng HMAC-MD5-96 trong ESP và AH. RFC2404 Việc sử dụng HMAC-SHA-1-96 trong ESP và AH. RFC2451 Các thuật toán mật mã chế độ ESP CBC.
1.11 Đàm phán nén1.11.1 Tổng quan 1.11.1 Tổng quan
Khả năng nén các bản tin SIP qua giao diện không khí là điều cần thiết đối với IMS. Thế nào hoạt động của Nén tín hiệu (SigComp) được mô tả trong Phần 3.18 Phần này cho thấy cách UE và P-CSCF chỉ ra rằng họ hỗ trợ SigComp và cả hai đều sẵn sàng sử dụng nó. P-CSCF và IMS UE phải hỗ trợ SIP SigComp, nhưng chúng không bắt buộc để dùng nó. Do đó, họ cần một cơ chế để thể hiện liệu họ có sẵn sàng áp dụng
SigComp. [RFC3486] xác định tham số URI mới ‘comp’, có thể được đặt thành ‘comp = Sig Comp’ bởi UE hoặc proxy SIP (trong trường hợp IMS, điều này chỉ áp dụng cho P-CSCF) để bày tỏ sự sẵn sàng gửi hoặc nhận các thông điệp SIP nhất định bị nén. Tobias’s UE sẽ bày tỏ sự sẵn lòng sử dụng SigComp với P-CSCF đã trong yêu cầu REGISTER ban đầu. P-CSCF sẽ đưa ra một chỉ báo tương tự trong 401 Phản hồi (trái phép). Khi hai bản tin SIP này được gửi đi mà không có bất kỳ biện pháp bảo vệ nào, P-CSCF và UE sẽ không tạo trạng thái (ngăn) cho SigComp tại thời điểm này trong thời gian; điều này là để đảm bảo rằng người dùng độc hại - người muốn bắt đầu từ chối dịch vụ (DOS) tấn công chống lại P-CSCF - không thể làm quá tải P-CSCF bằng cách buộc nó phải dự trữ bộ nhớ cho một số lượng lớn các ngăn SigComp không cần thiết. Việc tạo trạng thái sẽ chỉ được thực hiện sau một IPsec SA (xem Phần 1.10) giữa UE và P-CSCF đã được thành lập.
1.11.2 Thể hiện sự sẵn sàng sử dụng SigComp Tham số 'comp' có thể được đặt:
• bởi UE trong tiêu đề Liên hệ của yêu cầu REGISTER - điều này có nghĩa là UE sẵn sàng nhận mọi yêu cầu ban đầu dành cho nó được nén lại, như các yêu cầu ban đầu được gửi đến UE được định tuyến dựa trên địa chỉ liên hệ đã đăng ký địa chỉ
• bởi UE trong tiêu đề Liên hệ của bất kỳ yêu cầu ban đầu nào khác hoặc phản hồi đầu tiên cho một yêu cầu ban đầu - điều này có nghĩa là UE sẵn sàng nhận mọi yêu cầu tiếp theo trong hộp thoại này được nén, vì các yêu cầu tiếp theo được định tuyến dựa trên địa chỉ trong tiêu đề Liên hệ của yêu cầu ban đầu (từ đầu cuối) hoặc phản hồi đầu tiên đến một yêu cầu ban đầu (từ cuối kết thúc);
• bởi UE trong tiêu đề Via của bất kỳ yêu cầu nào - điều này có nghĩa là UE sẵn sàng nhận tất cả các phản hồi cho yêu cầu này được nén, vì các phản hồi được định tuyến dựa trên qua tiêu đề trong yêu cầu liên quan;
• bởi P-CSCF trong mục nhập của chính nó vào tiêu đề Tuyến đường Bản ghi được gửi
đến UE - điều này có nghĩa là P-CSCF sẵn sàng nhận các yêu cầu tiếp theo trong hộp thoại được nén, vì các yêu cầu tiếp theo được chuyển đến proxy SIP dựa trên các mục nhập trong tiêu đề Tuyến đường (được tạo từ tiêu đề Bản ghi-Tuyến đường)
• bởi P-CSCF trong tiêu đề Qua của bất kỳ yêu cầu nào - điều này có nghĩa là P-CSCF sẵn sàng để nhận tất cả các phản hồi cho yêu cầu này được nén, vì các phản hồi được định tuyến dựa trên tiêu đề Via trong yêu cầu liên quan.
1.11.3 comp = Tham số SigComp trong khi đăng ký
Yêu cầu REGISTER ban đầu của UE sẽ bao gồm các yêu cầu liên quan đến nén sau thông tin:
REGISTER sip:home1.fr SIP/2.0
Via: SIP/2.0/UDP sip:[5555::1:2:3:4]:1357;comp=SigComp ;branch=0uetb Route: sip:[5555:: a:b: c:d];lr
Contact: "Mobile Phone - Tobias"
<sip:[5555::1:2:3:4]: 1357; comp=SigComp > ;expires=600000
Tham số comp = SigComp được bao gồm trong tiêu đề Via và chỉ ra rằng UE sẵn sàng nhận tất cả các phản hồi cho yêu cầu này được nén. Do đó, P-CSCF có thể gửi phản hồi 401 (Trái phép) đã được nén, nhưng nó sẽ không tạo ra trạng thái (tức là một ngăn) vì điều này.
Tham số comp = SigComp cũng có thể được tìm thấy trong tiêu đề Liên hệ. Tham số ter này sẽ được đưa vào mọi yêu cầu ban đầu mà UE nhận được, như S-CSCF sẽthay thế URI yêu cầu (trỏ đến sip: tobias@home1.fr) của mọi yêu cầu ban đầu với địa chỉ liên hệ đã đăng ký (tức là sip: [5555 :: 1: 2: 3: 4]: 1357; comp = SigComp) Phản hồi 401 (Trái phép) từ P-CSCF không bao gồm bất kỳ thông tin nào khác về khả năng thực hiện SigComp của P-CSCF. Địa chỉ P-CSCF là được phát hiện trước khi đăng ký ban đầu (xem Phần 11.4) không thể được phát hiện với tham số comp = SigComp. Vì tin nhắn SIP chỉ nên được nén khi Tham số comp = SigComp được đặt trong địa chỉ của bước tiếp theo, do đó UE sẽ không gửi bất kỳ yêu cầu ban đầu nào đến P-CSCF đã nén.
Các yêu cầu tiếp theo (chẳng hạn như ACK, PRACK, UPDATE hoặc BYE) có thể được nhấn com, vì định tuyến từ UE đến P-CSCF sẽ dựa trên Record-Route mục nhập của P-CSCF (xem Phần 12.3.3.2), trong đó P-CSCF có thể bao gồm = Tham số
SigComp. Điều này cũng đúng đối với các phản hồi được gửi từ UE tới P-CSCF, vì chúng được định tuyến dựa trên mục nhập tiêu đề Via của P-CSCF, cũng được đặt bởi P-CSCF chính nó. Mặc dù nó là điều kiện cần để tham số comp cho biết liệu nén có đã sử dụng, 3GPP TS 24.229 không đưa ra yêu cầu rõ ràng về việc nén bản gốc thông điệp. Một khả năng là UE chỉ gửi mọi yêu cầu ban đầu được nén, vì P-CSCF phải hỗ trợ Sigcomp trong mọi trường hợp. Do đó, UE thêm tham số comp = SigComp vào địa
chỉ P-CSCF mà đã được phát hiện trước đây. Do đó, nó có thể gửi yêu cầu REGISTER
thứ hai đã được nén:
REGISTER sip:home1.fr SIP/2.0
Via: SIP/2.0/UDP sip:[5555:1:2:3:4]:1357;comp=SigComp;branch=1uetb Route: sip:[5555:a:b:c:d]:7531;lr;comp=SigComp
Contact: "Mobile Phone - Tobias"
<sip:[5555:1:2:3:4]:1357;comp=SigComp>; expires=600000
Yêu cầu REGISTER này được định tuyến dựa trên tiêu đề Tuyến đường trên cùng, bao gồm địa chỉ P-CSCF và tham số comp = SigComp. Như tham số là đã có, UE có thể gửi yêu cầu đã được nén. Phản hồi 200 (OK) cho yêu cầu REGISTER này sẽ được gửi từ P-CSCF tới UE trên cơ sở tiêu đề Via, và vì UE cũng bao gồm comp = SigComp ,