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

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

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

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

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

Как описано в [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].

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

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 Программирование для сетей (новые идеи, принципы и возможности)