Протоколы Internet
Идентификатор доступа к сети
6.10 Идентификатор доступа к сети
Семенов Ю.А. (ГНЦ ИТЭФ)
Бизнесмены хотели бы предложить своим служащим пакет услуг Интернет на глобальной основе. Эти услуги могут включать помимо традиционного доступа к Интернет, также безопасный доступ к корпоративным сетям через виртуальные частные сети (VPN), используя туннельные протоколы, такие как PPTP, L2F, L2TP и IPSEC в туннельном режиме.
Для того чтобы улучшить взаимодействие роуминга и сервиса туннелирования, желательно иметь стандартизованный метод идентификации пользователей. Ниже предлагается синтаксис для идентификаторов доступа к сети NAI (Network Access Identifier). Примеры приложений, которые используют NAI, и описания семантики можно найти в [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) |
/p> Примеры правильных идентификаторов сетевого доступа:
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]. Аналогично, существующие реализации не используют динамические протоколы маршрутизации или глобальную рассылку маршрутной информации.
Ссылки
