Ідентифікатор доступу до мережі

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук

Ідентифікатор доступу до мережі

Регіональні Інтернет сервіс-провайдери (ISP), що працюють в межах певної області або провінції, прагнуть об'єднати свої зусилля з іншими регіональними провайдерами, для того щоб забезпечити доступ до Інтернет через телефонну мережу в межах якомога більшого простору. Національні ISP хочуть поєднувати свої операції з одним або більше ISP в інших країнах, пропонуючи телефонний доступ до мережі в межах групи країн або навіть континенту. Бізнесмени хотіли б запропонувати своїм службовцям пакет послуг Інтернет на глобальній основі. Ці послуги можуть включати крім традиційного доступу до Інтернет, також безпечний доступ до корпоративних мереж через віртуальні приватні мережі (VPN), використовуючи тунельні протоколи, такі як PPTP, L2F, L2TP і IPSEC в тунельному режимі. Для того щоб поліпшити взаємодію роумінгу та сервісу тунелювання, бажано мати стандартизований метод ідентифікації користувачів. Нижче пропонується синтаксис для ідентифікаторів доступу до мережі NAI (Network Access Identifier). Приклади додатків, які використовують NAI, і опису семантики можна знайти в [1]. Тут використовуються такі визначення:

Мережі 1.jpg

Ідентифікатор доступу до мережі NAI

Ідентифікатор доступу до мережі (NAI) є ідентифікатором користувача, представленим клієнтом в ході PPP-аутентифікації. При роумінгу метою NAI служить ідентифікація користувача, а також сприяння маршрутизації запиту аутентифікації. Зауважте, що NAI не повинен бути обов'язково ідентичним його електронною адресою або userID, що видається на прикладному рівні для аутентифікації.

Сервер доступу до мережі

Сервер доступу до мережі NAS (Network Access Server) являє собою прилад, куди клієнт "дзвонить" щоб отримати доступ до мережі. У термінології PPTP це називається концентратором доступу PPTP (PAC), а в термінології L2TP, він називається концентратором доступу L2TP (LAC). Обсяг роумінгу Обсяг роумінгу можна визначити, як здатність використовувати будь-якого з наявних ISP, формально підтримуючи тільки одну взаємозв'язок покупець-продавець.

Мережі 2.gif

Тунельна послуга

Тунельної послугою є будь мережевий сервіс, що допускається протоколами туннелирования, такими як PPTP, L2F, L2TP і IPSEC в тунельному режимі. Прикладом тунельної послуги може служити безпечний доступ до корпоративної мережі через приватні віртуальні мережі (VPN).

Формальне визначення NAI

Граматика для NAI представлена нижче, описана в ABNF, як це представлено в [7]. Граматика для імен користувачів взята з [5], а граматика імен областей є модифікованою версією [4].

  • nai = username / (username "@" realm)
  • username = dot-string
  • realm = realm "." label
  • label = let-dig * (ldh-str)
  • ldh-str = * (Alpha / Digit / "-") let-dig
  • dot-string = string / (dot-string "." string)
  • string = char / (string char)
  • char = c / ("\" x)
  • let-dig = Alpha / Digit
  • Alpha =% x41-5A /% x61-7A; A-Z / a-z
  • Digit =% x30-39; 0-9
  • c = <any one of the 128 ASCII characters, but not any special or SP>
  • x =% x00-7F; all 127 ASCII characters, no exception
  • SP =% x20; Space character
  • special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." / "," / ";" / ":" / "@" /% X22 / Ctl
  • Ctl =% X00-1F /% x7F; the control characters (ASCII codes 0 through 31 inclusive and 127)

Приклади правильних ідентифікаторів мережевого доступу:

Приклади неправильних ідентифікаторів мережевого доступу:

У даному розділі визначено новий простір імен, яке повинно адмініструватися (NAI-імена областей). Для того щоб уникнути створення будь-яких нових адміністративних процедур, адміністрування іменних областей NAI покладається на DNS. Імена областей NAI повинні бути унікальними і право їх використання для цілей роумінгу оформляється згідно з механізмом, що застосовується для імен доменів FQDN (fully qualified domain name). При намірі використовувати ім'я області NAI потрібно спочатку надіслати запит щодо можливості застосування відповідного FQDN. Зауважте, що використання FQDN в якості імені області не передбачає звернення до DNS для локалізації сервера аутентифікації. В даний час аутентифікаційні сервери розміщуються зазвичай в межах домену, а маршрутизація цієї процедури базується на локальних конфігураційних файлах. Реалізації, описані в [1], не використовують DNS для пошуку аутентификационного сервера в межах домену, хоча це і можна зробити, використовуючи запис SRV в DNS, що описано в [6]. Аналогічно, існуючі реалізації не використовують динамічні протоколи маршрутизації або глобальну розсилку маршрутної інформації.

Використана література