The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа

previous up down next index index
Previous: 6.9 Квантовая криптография    UP: 6 Сетевая безопасность
Down: 7 Программирование для сетей (новые идеи, принципы и возможности)
    Next: 7 Программирование для сетей (новые идеи, принципы и возможности)

6.10 Идентификатор доступа к сети
Семенов Ю.А. (ГНЦ ИТЭФ)

Региональные Интернет сервис-провайдеры (ISP), работающие в пределах определенной области или провинции, стремятся объединить свои усилия с другими региональными провайдерами, для того чтобы обеспечить доступ к Интернет через телефонную сеть в пределах как можно большего пространства. Национальные ISP хотят совмещать свои операции с одним или более ISP в других странах, предлагая телефонный доступ к сети в пределах группы стран или даже континента.

Бизнесмены хотели бы предложить своим служащим пакет услуг Интернет на глобальной основе. Эти услуги могут включать помимо традиционного доступа к Интернет, также безопасный доступ к корпоративным сетям через виртуальные частные сети (VPN), используя туннельные протоколы, такие как PPTP, L2F, L2TP и IPSEC в туннельном режиме.

Для того чтобы улучшить взаимодействие роуминга и сервиса туннелирования, желательно иметь стандартизованный метод идентификации пользователей. Ниже предлагается синтаксис для идентификаторов доступа к сети NAI (Network Access Identifier). Примеры приложений, которые используют NAI, и описания семантики можно найти в [1].

Здесь используются следующие определения:

Идентификатор доступа к сети NAI

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

Сервер доступа к сети

Сервер доступа к сети NAS (Network Access Server) представляет собой прибор, куда клиент "звонит" чтобы получить доступ к сети. В терминологии PPTP это называется концентратором доступа PPTP (PAC), а в терминологии L2TP, он называется концентратором доступа L2TP (LAC).

Объем роуминга

Объем роуминга можно определить, как способность использовать любого из имеющихся ISP, формально поддерживая только одну взаимосвязь покупатель-продавец.

Туннельная услуга

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

Как описано в [1], существует много услуг, использующих телефонный доступ, а число провайдеров, предлагающих такие услуги (в том числе для подвижных пользователей) стремительно растет.

Для того чтобы обеспечить большой объем роуминга, одним из требований является способность идентифицировать "домашний" аутентификационный сервер пользователя. Эта функция в сети выполняется с помощью идентификатора NAI, посылаемого пользователем серверу NAS в процессе первичной PPP-аутентификации. Ожидается, что NAS будет использовать NAI как часть процесса открытия нового туннеля, с целью определения конечной точки этого туннеля.

Идентификатор доступа к сети имеет форму user@realm (но это не обязательно почтовый адрес). Заметьте, что в то время как пользовательская часть NAI согласуется с BNF, описанной в [5], BNF строки описания области допускает использования в качестве первого символа цифры, что не разрешено BNF, описанной в [4]. Это изменение было сделано с учетом сложившейся в последнее время практикой, FQDN, такое как 3com.com вполне приемлемо.

Заметьте, что хозяева NAS могут быть вынуждены модифицировать свое оборудование, чтобы обеспечить поддержку рассмотренного формата NAI. Оборудование, работающее с NAI должно работать с длиной кодов, по крайней мере, в 72 октета.

Формальное определение 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)

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

fred@3com.com
fred@foo-9.com
fred_smith@big-co.com
fred=?#$&*+-/^smith@bigco.com
fred@bigco.com
nancy@eng.bigu.edu
eng!nancy@bigu.edu
eng%nancy@bigu.edu

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

fred@foo
fred@foo_9.com
@howard.edu
fred@bigco.com@smallco.com
eng:nancy@bigu.edu
eng;nancy@bigu.edu
@bigu.edu

В данном разделе определено новое пространство имен, которое должно администрироваться (NAI-имена областей). Для того чтобы избежать создания каких-либо новых административных процедур, администрирование именных областей NAI возлагается на DNS.

Имена областей NAI должны быть уникальными и право их использование для целей роуминга оформляется согласно механизму, применяемому для имен доменов FQDN (fully qualified domain name). При намерении использовать имя области NAI нужно сначала послать запрос по поводу возможности применения соответствующего FQDN.

Заметьте, что использование FQDN в качестве имени области не предполагает обращения к DNS для локализации сервера аутентификации. В настоящее время аутентификационные серверы размещаются обычно в пределах домена, а маршрутизация этой процедуры базируется на локальных конфигурационных файлах. Реализации, описанные в [1], не используют DNS для поиска аутентификационного сервера в пределах домена, хотя это и можно сделать, используя запись SRV в DNS, что описано в [6]. Аналогично, существующие реализации не используют динамические протоколы маршрутизации или глобальную рассылку маршрутной информации.

Ссылки

[1]

Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC-2194, September 1997.

[2]

Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC-2138, April 1997.

[3]

Rigney C., "RADIUS Accounting", RFC-2139, April 1997.

[4]

Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC-1035, November 1987.

[5]

Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC-821, August 1982.

[6]

Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.

[7]

Crocker, D. and P. Overrell, "Augmented BNF for Syntax Specifications: ABNF", RFC-2234, November 1997.

[8]

Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC-2401, November 1998.

[9]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC-2119, March 1997.

Previous: 6.9 Квантовая криптография    UP: 6 Сетевая безопасность
Down: 7 Программирование для сетей (новые идеи, принципы и возможности)    Next: 7 Программирование для сетей (новые идеи, принципы и возможности)




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру