Electronic-Telecommunication. Together Discoverly New Technology
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82

Go down

Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82 Empty Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82

Post  telecom1988 Thu May 07, 2009 11:24 pm

Hiện nay, mạng xDSL đang được triển khai khá rộng rãi là mô hình mạng truy cập ATM DSL kết hợp với BRAS. Trong mô hình này, một kênh ảo thường trực (ATM PVC - Permanent Virtual Circuit) duy nhất được thiết lập giữa thiết bị khách hàng CPE (Customer Premise Equiment) ATM DSLAM và BRAS nhằm cung cấp điểm kết nối thường trực cho thuê bao.
Tuy nhiên, mô hình sử dụng kết nối ATM giữa DSLAM và BRAS có những hạn chế sau [2]: khả năng chia tải BRAS kém; tồn tại điểm hư hỏng đơn (single point of failure) tại ATM Switch, BRAS, sử dụng không hiệu quả về băng thông trong các ứng dụng đòi hỏi phát đa phương và quảng bá.
Vì vậy, xu hướng sử dụng các IP DSLAM hoặc Ethernet DSLAM để thay thế cho ATM DSLAM là một xu hướng tất yếu [3]. Việc phát triển mạng MAN và các ứng dụng phát đa phương như IPTV, VoD, … là điều kiện thuận lợi cho việc chuyển hướng sang mô hình không sử dụng giao thức điểm nối điểm (non-PPP). Quá trình cấu hình thiết bị đầu cuối bao gồm cấp phát địa chỉ IP, bộ định tuyến mặc định (default gateway), DNS server,… được thực hiện thông qua giao thức DHCP. Bên cạnh những ưu điểm của cấp phát cấu hình thiết bị linh động, giao thức DHCP cổ điển cũng bộc lộ những vấn đề bảo mật như sau:
- Cho phép một máy chủ DHCP giả mạo (rogue DHCP) hoạt động trên mạng, dễ bị tấn công dưới dạng làm cạn kiệt tài nguyên IP của hệ thống (IP Address Exhaustion), khả năng thay đổi thông tin ở DHCP Relay Agent. Do đó, cơ chế xác thực phải thực hiện ở cả ba đối tượng tham gia quá trình: DHCP Server, DHCP Relay Agent và DHCP client.
- DHCP server và DHCP relay Agent thường là do nhà khai thác dịch vụ nắm giữ, kiểm soát nhưng DHCP client là ở phía khách hàng và theo quan điểm khai thác là “không tin cậy”, do đó một số tính năng được bổ sung thêm như hỗ trợ “cấp người sử dụng” (User Class) (option 77) và đặc biệt là tính năng “Thông tin tác nhân chuyển tiếp” (Relay Agent Information) (Option 82) [4] được đưa vào mô hình.

Giao thức DHCP
Giao thức cấu hình thiết bị động (Dynamic Host Configuration Protocol –DHCP) [5] là một giao thức được thiết kế theo mô hình client/server nhằm cho phép các thiết bị mạng đóng vai trò DHCP client có thể dễ dàng lấy được các thông tin về cấu hình (địa chỉ IP, mặt nạ mạng con, địa chỉ bộ định tuyến mặc định, địa chỉ DNS server…) cần thiết từ DHCP server.
Các bản tin (message) dùng trong DHCP được mô tả trong Bảng 1.

Bảng 1: Các bản tin dùng trong DHCP


Bản tin
Mô tả
DHCPDISCOVER
Client gửi bản tin này dưới dạng quảng bá để tìm DHCP Server
DHCPOFFER
Bản tin trả lời của DHCP Server khi nhận được DHCPDISCOVER
DHCPREQUEST
Bản tin được client gửi đi, thực hiện một trong các việc sau:
+ Yêu cầu tham số từ một DHCP Server và từ chối các DHCP Server khác
+ Xác nhận lại tham số sau khi hệ thống thay đổi (ví dụ khi khởi động lại).
+ Yêu cầu tăng thêm thời gian sử dụng cho một địa chỉ IP cụ thể (Khi địa chỉ này sắp hết hạn sử dụng
DHCPACK
Bản tin do DHCP server gửi chấp nhận yêu cầu
DHCPNACK
Thông báo từ server cho client biết thời hạn sử dụng địa chỉ IP đã hết hoặc địa chỉ IP client yêu cầu không hợp lệ
DHCPDECLINE
Bản tin từ client cho server biết địa chỉ đã được dùng rồi
DHCPRELEASE
Bản tin từ client báo cho server biết không sử dụng địa chỉ IP đó nữa
DHCPINFORM
Bản tin từ client đã có địa chỉ IP yêu cầu các tham số cấu hình thêm từ server


Các bước cấp phát địa chỉ IP cho một nút mạng:

1. DHCP client gửi quảng bá bản tin DHCPDISCOVER trên mạng vật lý. Bản tin DHCPDISCOVER có thể chứa các giá trị gợi ý về địa chỉ mạng, thời gian sử dụng của client cho server.

2. Mỗi DHCP server trả lời bằng bản tin DHCPOFFER bao gồm thông tin về địa chỉ mạng, địa chỉ DHCP server, địa chỉ gateway... Địa chỉ mạng phải được đảm bảo là chưa được sử dụng (server có thể xác nhận điều này bằng cách dùng giao thức ICMP để kiểm tra xem địa chỉ này đã sử dụng chưa). Bản tin này được gửi quảng bá với địa chỉ MAC đích (destination MAC) là địa chỉ vật lý của client (địa chỉ này lấy từ địa chỉ MAC gửi đi trong bản tin DHCPDISCOVER).

3. DHCP Client nhận một hoặc nhiều bản tin DHCPOFFER và chọn lấy một DHCP server dựa trên các thông tin do DHCP server gửi đến. Sau đó DHCP client tạo ra bản tin DHCPREQUEST có chứa định danh của DHCP server được chọn và địa chỉ IP yêu cầu cấp phát. Bản tin này được gửi đi theo kiểu quảng bá. Trong trường hợp không nhận được bản tin trả lời nào, nếu có các thông số cấu hình trước đây và còn hạn sử dụng, DHCP client có thể dùng cho tới khi hết hạn.

4. Các DHCP server nhận được bản tin DHCPREQUEST có định danh khác mình sẽ coi như nhận được thông báo client bỏ qua. Chỉ có duy nhất một DHCP server chấp nhận bản tin này và tạo một bản tin DHCPACK để gửi đi dưới dạng quảng bá.

5. Các nút mạng nhận được frame chứa bản tin và so sánh địa chỉ MAC của mình với địa chỉ MAC đích trong frame. Chỉ có duy nhất một nút mạng có địa chỉ MAC phù hợp. Các thông số cấu hình trong DHCPACK được kiểm tra và thiết lập. Như vậy, nút mạng đã hoàn thành quá trình cấu hình.

Nếu phát hiện ra lỗi, DHCP client gửi bản tin DHCPDECLINE tới server và bắt đầu lại quá trình cấu hình. Để tránh tình trạng quá tải mạng, client sẽ đợi một khoảng thời gian (khoảng 10 giây) trước khi bắt đầu lại. DHCP Server nhận bản tin DHCPDECLINE sẽ đánh dấu địa chỉ đó không sử dụng được và có thể thông báo lỗi cho người quản trị.

Nếu DHCP client nhận được bản tin DHCPNACK, quá trình cấu hình cũng sẽ bắt đầu lại.

Cấu trúc của một bản tin DHCP như Bảng 2.

Bảng 2: Cấu trúc của một bản tin DHCP


8
16
24
32 bit
Op
Htype
Hlen
Hops
The transaction ID
Secs
Flags
Địa chỉ IP của client
Địa chỉ IP sẽ cấp cho client
Địa chỉ của server kế tiếp dùng trong bootstrap
Địa chỉ IP của relay agent.
Địa chỉ vật lý của client (MAC)
Tên máy chủ (64 bytes)
File (128 bytes)
Tùy chọn - Option (variable)


Trường option cho phép nâng cao độ linh hoạt và khả năng mở rộng của giao thức, cho phép các tính năng được bổ sung phục vụ cho các nhu cầu khác nhau.
telecom1988
telecom1988
Admin

Posts : 317
Join date : 2009-04-08
Age : 36
Location : 144 Xuan Thuy - Cau Giay - Ha Noi

https://banks.forum.st

Back to top Go down

Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82 Empty Re: Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82

Post  telecom1988 Thu May 07, 2009 11:26 pm

DHCP relay agent
Trong trường hợp DHCP client và DHCP không nằm cùng subnet và được kết nối qua bộ định tuyến (router) thì cần phải có giải pháp cho phép bản tin quảng bá DHCPDISCOVER từ DHCP client vượt qua router để đến DHCP server. DHCP relay agent (tác nhân chuyển tiếp DHCP) được dùng cho mục đích này. DHCP là một thực thể trung gian cho phép chuyển tiếp (relay) các bản tin quảng bá, mà thường bị chặn ở ngay router, từ DHCP client đến DHCP server. Ngoài ra, DHCP agent còn bổ sung các thông tin hữu ích vào các gói tin DHCP trước khi các gói tin này được chuyển tiếp.
Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82 DHCP%202310061
Hình 1: IP DSLAM với vai trò tác nhân chuyển tiếp DHCP


DHCP option 82
Như trên đã trình bày, giao thức DHCP cổ điển (không hỗ trợ option 82) chứa đựng nhiều vấn đề về bảo mật, nhất là vấn đề xác thực thuê bao. Vì vậy, để ISP có thể xác thực và điều khiển quyền cấp phát địa chỉ IP cho người dùng cuối, các DSLAM sẽ có tính năng DHCP relay agent (Hình 1) và hỗ trợ tùy chọn (option) “Relay agent information” hay còn gọi là “tùy chọn 82”. Khi nhận được gói tin DHCPDISCOVER, DSLAM sẽ đưa thêm các thông tin như địa chỉ kết nối hay mã định dạng của DSLAM trong trường option 82 rồi mới chuyển tiếp cho DHCP server. Nhờ vào các thông tin này mà việc quản lý thuê bao theo vị trí kết nối có thể thực hiện được.

Thực ra, option 82 bao gồm nhiều sub-option khác. Tuy nhiên, ban đầu chỉ có hai sub-option là được mô tả trong RFC3046 [4] theo bảng 3.


Bảng 3: Mã sub-option
Mã sub-option
Mô tả
1
Agent Circuit ID sub-option
2
Agent remote ID sub-option

Mặc dù, các nhà sản xuất thiết bị DSLAM như Alcatel, Cisco, Ericsson, Siemens đều có các sản phẩm hỗ trợ option 82 và đều tuân thủ RFC3046 nhưng định dạng option 82 của các nhà sản xuất này cũng không tương thích nhau hoàn toàn. Do đó, khi triển khai mô hình sử dụng DHCP cũng cần tính đến các yếu tố tương thích khi sử dụng các IP DSLAM của các nhà sản xuất khác nhau.

Vấn đề về bảo mật:
DHCP option 82 giải quyết được một số vấn đề liên quan đến bảo mật được giải quyết dựa trên một tiên đề là DHCP Relay server, DHCP server và mạng IP giữa chúng là tin cậy. Các vấn đề bảo mật được giải quyết bao gồm [4]:

- Bản tin quảng bá DHCP (Broadcast forwarding)
- Cạn kiệt địa chỉ DHCP (DHCP Address Exhausion)
- Gán địa chỉ tĩnh (Static Assigment)
- Giả địa chỉ IP (IP spoofing)
- Giả mã định danh khách hàng (client Identifier Spoofing)
- Giả địa chỉ MAC (MAC address spoofing)
Ngoài ra, DHCP server còn có thể kết hợp với hạ tầng AAA (Authentication, Authorization and Accounting) của nhà cung cấp dịch vụ mạng (ISP) để tăng cường khả năng xác thực và tính cước cho thuê bao như hình 2:
Cấu hình thiết bị đầu cuối cho mạng băng rộng với DHCP Option 82 DHCP%202310062
Hình 2: DHCP kết hợp với hạ tầng AAA

Kết luận:
Việc chuyển đổi mô hình cung cấp dịch vụ xDSL từ mô hình dựa trên ATM theo khuyến nghị TR- 059 [7] sang mô hình dựa trên nền tảng Ethernet theo khuyến nghị TR-101 là một xu hướng tất yếu. Nhưng đồng thời cũng kéo theo một loạt các vấn đề cần giải quyết trong đó có vấn đề cung cấp thông tin cấu hình và xác thực cho thiết bị đầu cuối. Giải pháp dùng DHCP có hỗ trợ Option 82 đã giải quyết được phần nào yêu cầu trên. Tuy nhiên trong một số trường hợp nó vẫn chưa đáp ứng được nhu cầu về an toàn và bảo mật (xem mục 5 của [4]) Vì vậy vẫn cần phải kết hợp một số các giải pháp khác như RADIUS, IEEE 802.1X,…


Tài liệu tham khảo
[1]. RFC 2516 - A Method for Transmitting PPP Over Ethernet, The Internet Society,1999
[2]. Đề tài khoa học: Giải pháp và lộ trình phát triển mạng xDSL trên nền NGN, Bưu điện TP. HCM, 10/2005.
[3]. Migration to Ethernet-Based DSL Aggregation (TR-101), DSL forum, 04/2006
[4]. RFC 3046 - DHCP Relay Agent Information Option, 01/2001
[5]. RFC 2131 - Dynamic Host Configuration Protocol, The Internet Society, 03/1997
[6]. Evolution to Triple Play Services, Hội thảo về Triple Play tại BĐ TP. HCM của Alcatel, 04/2006
[7]. DSL Evolution - ArchitectureRequirements for the Support ofQoS-Enabled IP Services (TR-059), DSL forum, 09/2003
telecom1988
telecom1988
Admin

Posts : 317
Join date : 2009-04-08
Age : 36
Location : 144 Xuan Thuy - Cau Giay - Ha Noi

https://banks.forum.st

Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum