IEEE802.1x

・IEEE802.1x
LANに接続したユーザを認証し，許可されたユーザーだけを通信させるようにする．
ユーザーがつながるLAN機器のポートを閉めたり，開けたりすることで実現する．

・必要となる機器
サプリカント，オーセンティケータ，認証サーバ

・サプリカント
認証をうけるパソコン（OS附属のソフト，専用ソフト）

・オーセンティケータ
サプリカントを収容するネットワーク機器（LANスイッチ，無線LANアクセスポイント）
接続ポートをON・OFFし，認証をクリアしたサプリカントだけをLANに通す役割をする．

・認証サーバ
ユーザを認証して通信を許可するかどうか判断する機器．判断した結果をオーセンティケータに
通知する役割をもつ．（RADIUSサーバが一般的）

・EAP(Extensible Authentication Protocol)
拡張可能なプロトコル
様々な認証方式の情報を運ぶためのプロトコル
IEEE802.1xでは，この仕組みを使って認証情報を運ぶ．
RFC3748で規定されている
PPPの仕組みを拡張したもの

PPPでは，認証方式としてPAP，CHAPを使用する．そこで，これ以外の様々な
認証方式に対応可能としたのがEAPである．
→IEEE802.1xではEAPのこの仕組みをつかい，様々な認証方式を使いわけられるようにした．

・サプリカントとオーセンティケータ間
→イーサネット，無線LANでつながっている
→EAPパケットをMACフレームで運ぶEAPOLを定めている．
→IEEE802.1xでLAN上でEAPパケットを運ぶためにEAPパケットをMACフレームの
データ部分にいれて運ぶ仕組み（EAPOL）

・EAPOLのMACフレーム

DA  ||　SA　|| Type(88-8E) ||データ :EAPOLフレーム(46-1500B)|| FCS(4B)

・データ(EAPOLフレーム)

バージョン(1B) || タイプ(1B)|| データ長(2B)||データ(EAPパケット)(42-1496B)

タイプ
0:EAP Packet(データ送信用)
 EAPパケットでユーザーIDや証明書といった認証データを
運ぶときにEAP Packetメッセージをもちいる．

1:EAPOL Start(通信の開始):EAP通信をはじめるときに使う．
EAPによる通信はサプリカントがEAPOL Startメッセージをサプリカントに出すか，
逆にオーセンティケータからサプリカントにEAPRequestメッセージを出したときに始まる.

※Windows附属のサプリカントはLANに接続しても自らEAPOL-Startメッセージを出さない．
そこで，オーセンティケータはクライアントの接続を検知したポートに対して，定期的にEAPの
Requestメッセージをおくるようにしている機器がおおい.

２：EAPOL Logoff(通信の終了)

3:EAPOL Key(暗号通信用の鍵情報の通知)
無線LANの場合はこのキーフレームを使って，鍵情報をおくる
オーセンティケータからサプリカントに暗号通信用の鍵情報を配布するための
EAPOL-Keyとよばれるメッセージ
キーフレームとよばれる．

IEEE802.1xをもちいると，このキーフレームのしくみを利用して，無線LANクライアント
に自動的に暗号鍵情報を通知できるようになる．
クライアントごとに毎回違う鍵情報を通知できるので安全面でメリットがある．

・EAPパケット
コード(1B) || ID(1B) || 長さ(2B) || タイプ(1B) || データ(可変長)

コード(1B):EAPの４つのメッセージの種類を示す.
１：Request
2:Response
3:Success
4:Failure

ID(1B)
要求(Requestメッセージ)と応答(Responseメッセージ)を対応づけるための番号
→認証サーバは新しいRequestメッセージを送信するたびにIDフィールドに違う値を設定する．
サプリカントがResponseメッセージのIDフィールドにRequestフレームに対応したID番号を
入れて返信する．

長さ(2B)
フレームのサイズ

タイプ(1B)
認証方式ごとに値がきめられている．
EAP-MD5:　4
EAP-TLS:　13
EAP-PEAP:25

データ
実際の認証で使われるユーザー名，証明書などがはいる．

・オーセンティケータと認証サーバ間
→EAPパケットをRADIUSで運ぶための拡張仕様を使う.

・EAPパケットを運ぶのに，サプリカントとオーセンティケータ間は
EAPOLをつかい，オーセンティケータと認証サーバ間はRADIUSの
拡張仕様をつかう．
→EAPパケットをやりとりするのは，サプリカントと認証サーバ間である．
→オーセンティケータはEAPパケットを中継する役割を果たす．
→認証の当事者間（サプリカントと認証サーバ間）でEAPパケットを
やりとりできるようにしている．

・認証の流れ
IEEE８０２．１ｘの通信は，サプリカントがLANにつながったときから始まる．
サプリカントはまず，認証サーバとEAPパケットをやりとりして，認証方式をきめる．
その後，実際の認証の作業にはいる．

・WindowsXP附属のサプリカントが標準でもっている方式
EAP-MD5
EAP-PEAP(ピープ)
EAP-TLS
→IEEE802.1xでは，これらの方式から選んで使う．

ユーザー認証がおわったら，認証サーバは許可，拒否の判断をして，その結果を
オーセンティケータに通知する．
→許可ならばオーセンティケータのポートを開いてサプリカントが通信できるようにする．
このとき，RADIUSサーバがオーセンティケータにVLAN情報を通知したり，オーセンティケータが
サプリカントに無線LANの暗号鍵情報を配布することも可能．

・EAPでは４つのメッセージを使って認証情報をやりとりする．
Requestメッセージ：認証サーバからサプリカントへの通信
Responseメッセージ；サプリカントから認証サーバへの通信

認証結果の通知：Success(認証成功) or Failure(認証失敗)というメッセージが使用される．
サプリカントと認証サーバはEAPパケットの先頭部分の”コード”部分に記述された数値によって
メッセージの種類が判断できる．

データ
実際の認証で使われるユーザー名，証明書などがはいる．

・RADIUSによる認証システム
→クライアント/サーバ方式
IEEE802.1xでは，オーセンティケータがRADIUSクライアントに相当し，認証サーバが
RADIUSサーバに相当する．この両者の間でRADIUS形式のパケットをやりとりする．

・RADIUSは，UDP上で動作するプロトコルである．
→RADIUSパケットはUDPパケットのデータ部分に入ってやりとりされる．
→MACヘッダー||IPヘッダー||UDPヘッダー||RADIUSパケット

・RADIUSサーバには，あらかじめ認証対象となるユーザーの認証情報をデータベースとして
格納しておく．
→IEEE802.1xでは，RADIUSサーバーがオーセンティケータから認証情報を受け取り，自身の
データベースに記載された情報をつかって許可・拒否を判断し，その結果をオーセンティケータに
返信する.

・IEEE802.1xでは，LANでRADIUSの仕組みを利用するにあたって，RADIUSの中核機能を
拡張する２つの仕組みを取り入れている．
→RADIUSでEAPパケットを運ぶための仕組み，LAN特有の情報をRADIUSで扱う仕組み
→RADIUSパケットに入るデータがEAPパケットであることを示す値（タイプ値）が７９番と定義されている．

・RADIUSパケット
コード(1B) || 識別子 (1B) || パケット長(2B) || 認証符号(16B) || 属性データ1 || 属性データ２

・コード
1:Access-Request
2:Access-Accept
3:Access-Reject
11:Access-Challenge

・識別子
要求と応答を対応づけるための番号

・認証符号
データの整合性チェックなどに利用

・属性データ
タイプ(1B)||データ長(2B)||データ(可変長)

・RADIUSで扱うデータは，「属性データ」とよばれている．属性とは，そのデータの種類をあらわした情報
である．データの属性はRADIUSパケット内に入る個々のデータに記述された”タイプ値”で識別する．
→RADIUSパケットでEAPパケットを運ぶときは，タイプは７９番

・サプリカントとオーセンティケータの間：EAPOLで EAPパケットをMACフレームにいれて運ぶ．
→このEAPパケットをうけとったオーセンティケータは，MACフレーム内のEAPパケットを取り出し，
そのままRADIUSパケットのデータとして乗せ替えて，RADIUSサーバにおくる．
→このときデータの属性を示すタイプ値を７９番として，EAPパケットであることを示す．
→サプリカントとRADIUSサーバでEAPパケットをやりとりできるようになる．

・IEEE８０２．１ｘでLAN特有の情報を通知するための仕組み
→オーセンティケータにユーザーごとのVLAN番号を割り当てる「認証VLAN」を実現する．

・VLAN番号を割り当てるときは，RADIUSサーバがオーセンティケータに
”Tunnel-Type（トンネルタイプ）”,”Tunnel-Medium-Type(トンネルメディアタイプ)”，
”Tunnel-Private-Group-Id”という３つのタイプの属性データを通知する．

・Tunnel-Typeのデータ部分には，VLANを示す"13"，Tunnel-Medium-Typeは
イーサネットでは"6"を入れることがきまっている．そして，Tunnel-Private-Group-Idの
データ部分にVLAN番号が入る．
→認証VLAN機能を持つLANスイッチはRADIUSサーバから通知されたこの３つのデータの
属性を解釈して，ポートにVLANを設定する．

・EAP-MD5方式
チャレンジ・レスポンス方式
→パスワードを生の状態でやりとりしない方式
認証サーバがサプリカントにチャレンジコードとよばれる乱数を送る．
サプリカントはそのチャレンジコードとパスワードをMD５と呼ばれる
ハッシュ関数を用いて，レスポンスコードをつくり，認証サーバに返信する．
認証サーバも同じMD５のハッシュ関数を使って，そのレスポンスコードを検証することで
通信相手のパスワードを検証する．

・IEEE802.1xで用いられる認証方式

・EAP-MD5(ユーザーID，パスワード)
サプリカントに証明書などをインストールする必要がない．
→導入や管理の手間がかからないが，セキュリティ面で不安がある．
→チャレンジコードとレスポンスの組み合わせからパスワードが推測される危険性がある．

・EAP-PEAP(SSLの仕組みを使う)
Webアクセス暗号化プロトコルであるSSLの仕組みをつかった認証方式．
→パソコンとWebサーバで暗号通信用の鍵を共有し，その共有鍵を使って実際にやりとりする
データを暗号化する．（パソコンとWebサーバ間でしかやりとりできない暗号トンネルを作り，そのトンネル
中で実際のデータを通すイメージ）

EAP-PEAPでは，暗号化トンネルをつくるところまでは，SSLと同様．
その先，EAP-PEAPでは，あの暗号化トンネル内でIDとパスワードをやりとりする．
デフォルトでは，”EAP-MSCHAP　ｖ２”というチャレンジ・レスポンス方式の認証方式を使用する．

サーバにSSLと同様に”サーバ証明書”が必要．一方，クライアントにはサーバ証明書が
自分の信頼したサーバーの証明書であることを検証するために”ルートCA証明書”が必要になる．

・EAP-TLS(お互いに証明書を交換する)
サプリカントとサーバのお互いで自身の証明書を交換しあう方式
→証明書の検証をサプリカントとサーバーで相互に実施する．
→最初にサーバーがサプリカントに証明書を送付し，サプリカントは自身のルートCA証明書を
使用してそのサーバ証明書を検証する．検証がクリアできたら，クライアント証明書をサーバに送付する．
サーバも自身のルートCA証明書でクライアント証明書を検証し，検証がクリアできたら認証成功である．
→セキュリティ強度が高いが，導入や管理に手間がかかる.

SPI(Serial Peripheral Interface)

１．SPIとは

・Serial Peripheral Interface　の略

※メーカーの呼び方でSSI(Serial Synchronous Interface)とも呼ばれることもあるが，
SPIの方が一般的です．

SPIは、米国モトローラ社（現在フリースケール社）が提唱する3線式の同期式シリアル通信インターフェースです。

・方式

(1)同期シリアル通信，３線式

※データ出力信号SDO、データ入力信号SDI、クロック信号SCKの3本の信号で通信します。

※シリアル・クロックSCKは単方向の信号で、マスタは出力、スレーブは入力です。
データの入出力信号はSDI（入力）とSDO（出力）の2つあり、それぞれ単方向の信号です。したがって、マスタとスレーブを接続する際は、マスタのSDIはスレーブのSDO、マスタのSDOはスレーブのSDIというようにクロス結線にする必要があります。
　その他、スレーブ・セレクト信号SSはマスタが出力、スレーブが入力で、“L”レベルでアクティブ（選択状態）となります。複数のスレーブを接続する場合はマスタには複数のSS信号出力が必要で、スレーブ選択時は複数の中の一つだけがアクティブになります。


(2)通信機器同士がマスタ・スレーブという主従関係にあり，同一バス上に
複数のデバイスが容易に接続できる．

※基本的にはマスタ・デバイス一つに対してスレーブ・デバイスが一つが接続されるような形になりますが、スレーブ選択する信号(SS)をマスタからスレーブへ与えることで、複数のスレーブをバス接続することもできます。

・仕組み

SPIの原理はシフト・レジスタの原理そのものです。送信出力部はパラレル→シリアル変換型のシフト・レジスタで作られていて、マスタが生成するシフト・クロック（SCK；シリアル・クロック）でパラレル・データがシリアル信号に変換されます。一つのクロックで1ビット分の信号が出力されます。
　受信部は、シリアル→パラレル変換型のシフト・レジスタで作られています。送信側から送られてきたシリアル信号を、マスタが生成するシフト・クロックでサンプリングして、パラレル・データに変換します。
※シフトレジスタのMSBから出力する．

・通信速度

通信レートの規定はないようです．Max.1.5Mbpsほど．

・他の方式との比較

I2Cも，SPIと同様に同期式シリアルです．ただこっちは，スレーブのセレクトに
アドレス指定で行います．あと，データ線（SDA）が双方向です．

通信レートには、標準モード(最大100kbps)とファースト・モード(最大400kbps)、高速モード(最大3.4Mbps)の三つが規定されています。

MIB

・MIB
読み方 ： ミブ
フルスペル ： Management Information Base

　SNMPで管理されるネットワーク機器が、自分の状態を外部に知らせるために公開する情報のこと。RFC 1156として規定されているMIB1と、RFC 1213で規定されているMIB2があり、現在では後者を使うのが一般的。

・SNMP

読み方 ：	エスエヌエムピー
フルスペル ：	Simple Network Management Protocol

　TCP/IPネットワークにおいて、ルータやコンピュータ、端末など、ネットワークに接続された通信機器をネットワーク経由で監視・制御するためのプロトコル。制御の対象となる機器はMIBと呼ばれる管理情報データベースを持っており、管理を行なう機器は対象機器のMIBに基づいて適切な設定を行なう。
 

SFI

・SerDes Framer Interface is abbreviated as SFI. Some commonly used SFI variants include:

SFI-4: SerDes Framer Interface Level-4
SFI-5: SerDes Framer Interface Level-5

SerDes Framer Interface Level 5 or SFI-5 is a standardized Electrical Interface standard by the OIF for connecting a Sonet Framer component to an optical SerDes for OC-768 (40 Gbit/s).[1] Electrically, it consists of 16 pairs of SerDes channels each running at 3.125Gbit/s which gives an aggregate bandwidth of 50Gbit/s accommodating up to 25% of Forward Error Correction

・OIF
Optical Internetworking Forum
From Wikipedia, the free encyclopedia
Jump to: navigation, search
The Optical Internetworking Forum (OIF) was organized to facilitate and accelerate the development of next-generation optical internetworking products. The OIF produces Electrical, Tunable Laser, Very Short Reach Hardware Interfaces. It also has produced a UNI and NNI software interface Interoperability Agreements. These agreements enable equipment manufacturers to lower their time to market and development cost by enabling a robust, multi-vendor ecosystem. It also lowers the total cost of ownership of systems based on their interoperability agreements by enabling investments in test and verification infrastructure as well as enabling competition.
 

SCB

・SingleCopyBroadcast

P2PEの例外として，下り通信に関してブロードキャ
ストLLIDと呼ばれる特別なLLIDが定義されています．
ONUは受信フレームがブロードキャストLLIDを持つ場合
は，無条件にそのフレームを取り込みます．メディアコ
ンバータ（MC:  Media  Converter）などのP2Pシステム
でブロードキャストフレームやマルチキャストフレーム
を転送する際には，転送対象となるMCの数だけフレーム
をコピーしてから個別にMCに送る必要があるため，コ
ピーに処理時間を要し,帯域使用効率が低下するという問
題がありました．一方，GE-PONシステムではブロード
キャストLLIDを使うことによりフレームをコピーするこ
となく全ONUに転送可能なため，下り同報配信に適した
システムであるといえます．

3. Multicast Distribution Technology
One  of the important factors in the triple-play ser-
vice  with GE-PON will be video  distribution  using mul-
ticast  technology.  In  addition  to  the  LLID  allocated  to
each ONU as introduced in Chapter 2, broadcast LLID
defined  for  GE-PON  allows  all  of  the  logical  links  to
receive  data.  Broadcasting  without  frame-copying  is
enable  to  utilize  the  broadcast  LLID.  This  method  is
called the SCB (Single Copy Broadcast) method and is
used  for  multicast  distribution  based  on  the  broadcast
LLID  as  shown  in  Figure  4.  In  this  case,  frame  filters
above the RS layer should be implemented on the ONU
as the multicast frame is distributed to all of the ONU.
Notwithstanding the above, a certain means to effi-
ciently and surely send frames to only the ONUs within
the multicast group and a method to distribute encryp-
tion keys for multicasting is essential for the establish-
ment of secure multicast distribution.
Multicast distribution requires filters to be installed
on the ONUs so that only the ONUs within the multicast
group receive the broadcast frames forwarded to all of
the  ONUs.  For  this  particular  purpose,  we  propose  a
method of group identification that combines the group
control  information  with  encryption  technology.  The
encryption  keys  for  multicasting  are  generated  on  the
basis  of  the  group  control  information  by  the  OLT  and
shared by multiple ONUs that belong to a certain group.
Any ONUs without the key cannot decrypt the data. In
other  words,  multicast  frames  encrypted  by  means  of
the key are filtered at the ONUs which are not included
in  the  multicast  group.  When  the  delivered  frames  are
encrypted  in  this  manner,  the  encryption  function  can
also serve as identifiers.
It must be noted, however, that encryption keys in
the case of applying the encryption method to multicast
communication  should  preferably  be  generated  and
delivered  to  ONUs  by  the  OLT  as  shown  in  Figure  5,
because  the  group  control  is  executed  on  the  OLT.
Furthermore, use of a different encryption key (such as
an  encryption  key  for  the  existing  unicast  distribution)
for the encryption of the encryption key information for
multicast,  as  shown  in  Figure  6,  can  provide  a  safe
means of communication with the ONUs.
In this way, efficient and secure multicast distribu-
tion  systems  can  be  realized  by  combining  the  SCB
technology,  which  is  one  of  the  features  of  PON,  with
encryption technology and the group control method.
With  the  recent  remarkable  progress  in  the  infor-
mation  infrastructure,  optical  access  service  strategies
based  on  the  GE-PON  for  FTTH  implementation  are
increasingly  being  introduced.  Mitsubishi  will  continue
aaaa
to  develop  technologies  for  GE-PON  systems  to  con-
tribute to the use of FTTH in the future.