RINA (Recursive Internetworked Architecture)

RINA (Recursive Internetworked Architecture) Nội dung
Xem nhanh Ẩn

Kiến trúc mạng liên kết đệ quy (RINA - Recursive Internetworked Architecture) là một kiến ​​trúc mạng máy tính mới được đề xuất thay thế cho kiến ​​trúc của bộ giao thức Internet phổ biến hiện nay. Các nguyên tắc cơ bản của RINA là mạng máy tính chỉ là Giao tiếp giữa các quá trình hoặc IPC và việc phân lớp phải được thực hiện dựa trên phạm vi / quy mô, với một bộ giao thức lặp lại duy nhất, thay vì dựa trên chức năng, với các giao thức chuyên biệt. Các thể hiện giao thức trong giao diện một lớp với các thể hiện giao thức trên các lớp cao hơn và thấp hơn thông qua các khái niệm và thực thể mới có hiệu quả sửa đổi các chức năng mạng hiện dành riêng cho các giao thức như BGP ,OSPF và ARP. 

Theo cách này, RINA tuyên bố sẽ hỗ trợ các tính năng như tính di động, đa kênh và chất lượng dịch vụ mà không cần các giao thức chuyên biệt bổ sung như RTP và UDP , cũng như cho phép quản trị mạng đơn giản mà không cần đến các khái niệm như hệ thống tự trị và NAT.

Năm 1972: Multihoming không được ARPANET hỗ trợ 

Năm 1972, Căn cứ Không quân Tinker muốn kết nối với hai IMP khác nhau để dự phòng. Các nhà thiết kế ARPANET nhận ra rằng họ không thể hỗ trợ tính năng này vì địa chỉ máy chủ lưu trữ là địa chỉ của số cổng IMP mà máy chủ lưu trữ được kết nối (mượn từ điện thoại). Đối với ARPANET, hai giao diện của cùng một máy chủ có địa chỉ khác nhau; nói cách khác, địa chỉ quá thấp để xác định máy chủ.

Năm 1978: TCP tách khỏi IP 

Các phiên bản TCP ban đầu đã thực hiện các chức năng kiểm soát lỗi và luồng (TCP hiện tại) và chuyển tiếp và ghép kênh (IP) trong cùng một giao thức. Năm 1978 TCP được tách khỏi IP mặc dù hai lớp có cùng phạm vi. Đến năm 1987, cộng đồng mạng đã nhận thức rõ về vấn đề phân mảnh IP, đến mức coi nó có hại. Tuy nhiên, nó không được hiểu là một dấu hiệu cho thấy TCP và IP phụ thuộc lẫn nhau.

Năm 1981: Kết quả cơ bản của Watson bị bỏ qua 

Richard Watson vào năm 1981 đã đưa ra một lý thuyết cơ bản về truyền tải đáng tin cậy [9] theo đó việc quản lý kết nối chỉ yêu cầu các bộ định thời bị giới hạn bởi một yếu tố nhỏ của Thời gian sống của gói tối đa (MPL). Dựa trên lý thuyết này, Watson et al. đã phát triển giao thức Delta-t cho phép xác định trạng thái của kết nối đơn giản bằng cách giới hạn ba bộ định thời, không cần bắt tay. Mặt khác, TCP sử dụng cả tính năng bắt tay rõ ràng cũng như quản lý trạng thái của kết nối dựa trên bộ đếm thời gian hạn chế hơn.

Năm 1983: Lớp kết nối Internet bị mất 

Đầu năm 1972, Nhóm Công tác Mạng Quốc tế (INWG) được thành lập để tập hợp cộng đồng nghiên cứu mạng non trẻ lại với nhau. Một trong những nhiệm vụ ban đầu mà nó hoàn thành là bỏ phiếu cho một giao thức truyền tải mạng quốc tế, được phê duyệt vào năm 1976. Đáng chú ý, phương án được chọn, cũng như tất cả các ứng cử viên khác, có kiến ​​trúc bao gồm ba lớp với phạm vi ngày càng tăng: liên kết (để xử lý các loại phương tiện vật lý khác nhau), mạng (để xử lý các loại mạng khác nhau) và internetwork (để xử lý một mạng các mạng), mỗi lớp có không gian địa chỉ riêng. Khi TCP / IP được giới thiệu, nó đã chạy ở lớp internetwork trên NCP. Nhưng khi NCP ngừng hoạt động, TCP / IP đảm nhận vai trò mạng và lớp kết nối internet bị mất.Điều này giải thích sự cần thiết của các hệ thống tự quản và NAT ngày nay, để phân vùng và tái sử dụng các phạm vi của không gian địa chỉ IP để tạo điều kiện quản trị.

Năm 1983: Cơ hội đầu tiên để sửa lỗi địa chỉ bị bỏ lỡ 

Sự cần thiết của một địa chỉ cấp cao hơn địa chỉ IP đã được hiểu rõ từ giữa những năm 1970. Tuy nhiên, tên ứng dụng đã không được giới thiệu và DNS được thiết kế và triển khai, tiếp tục sử dụng các cổng nổi tiếng để xác định ứng dụng. Sự ra đời của web và HTTP đã tạo ra nhu cầu về tên ứng dụng, dẫn đến các URL. Tuy nhiên, URL liên kết mỗi phiên bản ứng dụng với giao diện vật lý của máy tính và kết nối truyền tải cụ thể, vì URL chứa tên DNS của giao diện IP và số cổng TCP, gây ra các vấn đề về đa kênh và di động cho các ứng dụng.

Năm 1986: Sự cố tắc nghẽn gây bất ngờ cho Internet 

Mặc dù vấn đề kiểm soát tắc nghẽn trong mạng datagram đã được biết đến từ những năm 1970 và đầu những năm 80, sự cố tắc nghẽn vào năm 1986 đã khiến Internet bất ngờ. Điều tồi tệ hơn, việc kiểm soát tắc nghẽn được thông qua - sơ đồ tránh tắc nghẽn Ethernet , với một vài sửa đổi - đã được đưa vào TCP.

Năm 1988: Quản lý mạng có một bước lùi 

Năm 1988, IAB khuyến nghị sử dụng SNMP làm giao thức quản lý mạng ban đầu cho Internet để sau này chuyển đổi sang cách tiếp cận hướng đối tượng của CMIP. SNMP là một bước lùi trong quản lý mạng, được coi là một biện pháp tạm thời trong khi các phương pháp tiếp cận phức tạp hơn được yêu cầu đã được thực hiện, nhưng quá trình chuyển đổi chưa bao giờ xảy ra.

Năm 1992: Cơ hội thứ hai để sửa lỗi địa chỉ bị bỏ lỡ 

Vào năm 1992, IAB đã đưa ra một loạt các khuyến nghị để giải quyết các vấn đề về quy mô của Internet dựa trên IPv4: tiêu thụ không gian địa chỉ và bùng nổ thông tin định tuyến. Ba phương án đã được đề xuất: giới thiệu CIDR để giảm thiểu vấn đề; thiết kế phiên bản tiếp theo của IP (IPv7) dựa trên CLNP ; hoặc tiếp tục nghiên cứu đặt tên, địa chỉ và định tuyến. CLNP là một giao thức dựa trên OSI giải quyết các nút thay vì giao diện, giải quyết vấn đề đa kênh cũ có từ thời ARPANET và cho phép tổng hợp thông tin định tuyến tốt hơn. CIDR đã được giới thiệu, nhưng IETFkhông chấp nhận IPv7 dựa trên CLNP. IAB đã xem xét lại quyết định của mình và quá trình IPng bắt đầu, đỉnh điểm là IPv6 . Một trong những quy tắc đối với IPng là không thay đổi ngữ nghĩa của địa chỉ IP, điều này tiếp tục đặt tên cho giao diện, gây ra vấn đề đa kênh.

  • Độ phức tạp khi truyền: việc tách IP và TCP dẫn đến không hiệu quả, với việc khám phá MTU được thực hiện để ngăn phân mảnh IP là dấu hiệu rõ ràng nhất.
  • Hiệu suất: Bản thân TCP mang chi phí khá cao với sự bắt tay của nó, điều này cũng gây ra các lỗ hổng như lũ lụt SYN. Ngoài ra, TCP dựa vào việc giảm gói tin để tự điều chỉnh và tránh tắc nghẽn, có nghĩa là việc kiểm soát tắc nghẽn của nó hoàn toàn là phản ứng, không chủ động hoặc phòng ngừa. Điều này tương tác xấu với các bộ đệm lớn, dẫn đến đệm. 
  • Đa kênh: Địa chỉ IP và số cổng quá thấp để xác định một ứng dụng trong hai mạng khác nhau. DNS không giải quyết được điều này vì tên máy chủ phải phân giải thành một tổ hợp địa chỉ IP và số cổng duy nhất, khiến chúng trở thành bí danh thay vì danh tính. LISP cũng vậy, bởi vì i) nó vẫn sử dụng bộ định vị, là một địa chỉ IP, để định tuyến, và ii) nó dựa trên sự phân biệt sai lầm, trong đó tất cả các thực thể trong một phạm vi đều được định vị bởi số nhận dạng của chúng để bắt đầu. Ngoài ra, nó cũng đưa ra các vấn đề về khả năng mở rộng của riêng nó.
  • Tính di động: Địa chỉ IP và số cổng cũng ở mức quá thấp để xác định một ứng dụng khi nó di chuyển giữa các mạng, dẫn đến phức tạp cho các thiết bị di động như điện thoại thông minh. Mặc dù là một giải pháp, nhưng Mobile IP trên thực tế chuyển hoàn toàn vấn đề sang địa chỉ Care-of và đưa vào một đường hầm IP, với độ phức tạp của người phục vụ.
  • Quản lý: Bản chất cấp thấp giống nhau của địa chỉ IP khuyến khích nhiều địa chỉ hoặc thậm chí dải địa chỉ được phân bổ cho các máy chủ duy nhất, [5] gây áp lực phân bổ và đẩy nhanh tốc độ cạn kiệt. NAT chỉ trì hoãn việc giải quyết tình trạng cạn kiệt và có khả năng gây ra nhiều vấn đề hơn. Đồng thời, việc phân lớp chức năng của kiến ​​trúc bộ giao thức Internet chỉ để lại khoảng trống cho hai phạm vi, làm phức tạp thêm việc phân chia quản trị Internet và đòi hỏi khái niệm giả tạo về các hệ thống tự trị. OSPF và IS-IS có tương đối ít vấn đề, nhưng không mở rộng quy mô tốt, buộc phải sử dụng BGP cho các mạng lớn hơn và định tuyến liên miền.
  • Bảo mật: Bản chất của không gian địa chỉ IP dẫn đến bảo mật yếu, vì không có chính sách có thể định cấu hình thực sự để thêm hoặc xóa địa chỉ IP ngoài việc ngăn chặn việc đính kèm về mặt vật lý. TLS và IPSec cung cấp các giải pháp, nhưng đi kèm với sự phức tạp. Tường lửa và danh sách đen dễ bị lấn át, không thể mở rộng. "[...] kinh nghiệm đã chỉ ra rằng rất khó để thêm bảo mật vào một bộ giao thức trừ khi nó được xây dựng vào kiến ​​trúc ngay từ đầu."

Để phù hợp với bảo mật, RINA yêu cầu mỗi DIF / DAF phải chỉ định một chính sách bảo mật, các chức năng của chúng được thể hiện ở hình dưới.

Tổ chức bảo mật. (Nguồn: wikipedia.org)

 Điều này cho phép không chỉ bảo mật các ứng dụng mà còn cả xương sống và chính các loại vải chuyển đổi. Mạng công cộng chỉ đơn giản là một trường hợp đặc biệt mà chính sách bảo mật không làm gì cả. Điều này có thể giới thiệu chi phí chung cho các mạng nhỏ hơn, nhưng nó mở rộng quy mô tốt hơn với các mạng lớn hơn vì các lớp không cần phối hợp các cơ chế bảo mật của chúng: Internet hiện tại được ước tính là yêu cầu các thực thể bảo mật khác biệt gấp 5 lần so với RINA. Trong số những thứ khác, chính sách bảo mật cũng có thể chỉ định một cơ chế xác thực; điều này làm hỏng tường lửa và danh sách đen vì DAP hoặc IPCP không thể tham gia DAF hoặc DIF không thể truyền hoặc nhận. DIF cũng không để lộ địa chỉ IPCP của chúng ở các lớp cao hơn, ngăn chặn nhiều loại tấn công trung gian.

Bản thân thiết kế của giao thức Delta-T, với sự nhấn mạnh vào tính đơn giản, cũng là một yếu tố. Ví dụ, vì giao thức không có bắt tay, nên nó không có thông điệp điều khiển tương ứng có thể bị giả mạo hoặc trạng thái có thể bị sử dụng sai, giống như trong SYN lũ. Cơ chế đồng bộ hóa cũng làm cho hành vi sai lệch tương quan hơn với các nỗ lực xâm nhập, làm cho các cuộc tấn công dễ bị phát hiện hơn nhiều.