$Id: sctp.jhtml,v 1.22 2004/12/15 03:32:14 nishida Exp $

SCTP related docs



http://www.sctp.de
http://www.sctp.org

RFCs


An Introduction to the Stream Control Transmission Protocol (SCTP) (RFC3286)
Category: Informational

SCTPの特徴をまとめたもの。
  • High-Reliable and full-duplex communication
  • message orientedなのでメッセージの境界で framingできる。(TCPは byte orientedで構造を持たない)
  • TCPと同様の輻輳制御アルゴリズム
  • Multi-Streaming
    データを複数のストリームに分割できる。あるストリームの lossや delayは他の ストリームに影響を与えない。
  • Multi-Homing
    endpointで複数のIPアドレスを持つことができる。この機能を使うためには、 associationセットアップ時に addressのリストを交換する必要がある。
    セキュリティの向上のために、response messageの中にはソースアドレス に対して（アドレスリストのうちからpickupするのではなく) 送らなければいけないものもある。
  • 通信の開始処理
    TCPの3way-handshakeに対して、SCTPは4messageを交換して初期化処理を行う。
    ３番目と４番目のメッセージにはデータを含んでも良い。DoSに対抗するため、 この処理は cookieを利用する。INIT chunkを受信したサーバは TCB用のメモリを allocする代わりに、TCB情報とlifetimeとsignatureの情報から cookieを作成し、 INIT ACK chunkで返送する。INIT ACKはソースアドレスに必ず送信され、 クライアントは COOKIE ECHO chunkを返送しなければならない。
  • データ転送
    SCTPは TCPのSACKと同様の機能を持ち、cumulativeなTSNのACKを返すだけでなく gapの情報も与えることができる。ACKは通常 delayed ACKで送信する。
    アプリケーションはデータの lifetimeを指定できる.lifetimeを経過した データの受信は無視できる。パケットの再送は 連続する4つ SACKの受信に対して 行われる。
  • 通信終了 SCTPは TCPの様なhalf-openはサポートしない。一方の通信終了は双方の 終了を意味する。
  • SCTPのメッセージフォーマットは一つのcommon headerと一つ以上の chunkから 構成される。
  • ACKが返送されない再送数をカウントし、一定数を超えた場合そのアドレスは inactiveと見なす。inactiveなdestinationを検出するために、idleのdestination に対して一定間隔で heartbeatが送られる。すべてのdestinationがunreachの 状態が続く場合はendpointが unreachableとみなす。


Stream Control Transmission Protocol Applicability Statement (RFC3257)
Category: Informational

SCTPと他のトランスポートプロトコルを比較し、適応分野などについて解説したもの。
SCTPの特徴
  • multi-streams
  • multi-homing
  • アプリケーションのメッセージ境界を保持できる。
  • unorderedなデータ配送や unreliableなデータ転送が可能。
multi-homingの機能は通信する２者のどちらかが複数の IPアドレスを持つ場合に 利用できる。ソースアドレスは、パケットが送出されるネットワークインターフェース に対応するIPアドレスを選択すべき。

NATを利用してmulti homingする場合、NAT routerは2つのエンドポイントアドレスを assignしなければならない。したがって、NAT routerで INITと INIT ACK chunkを tweakするか、DNSを利用して INIT、INIT ACKのエンドポイントをホスト名で指定する 必要がある。

TCPは、SYN Flood Attackの危険性があるが、SCTPは 32bitのVerification Tagが あるので安全性が高い。


Stream Control Transmission Protocol (SCTP) Checksum Change (RFC3309)
Category: Standard

RFC2960では SCTPのchecksumアルゴリズムは adler-32になっているが、 adler-32のアルゴリズムは 128 bytes程度の小さなデータに対してchecksumを 計算する場合に脆弱性の問題がある。 このため、SCTPの checksumアルゴリズムを alder-32から CRC-32cへ変更した。この変更により RFC2960中の alder-32への言及は すべて CRC-32cに置き換えて解釈されなければならない。


SCTP Partial Reliability Extension (RFC3758)
データ転送に部分的な信頼性を与えるサービスを提供する SCTPの extentionの提案。

PR-SCTPのメリット
  • 単一の SCTP associationで reliableな contentと unreliableな contentを転送できる。
  • peerの通信障害を素早く検出することができる。
  • orderedな unrealiable data 転送サービスを提供できる。
  • unreliableと reliableなフローに対して同じ Congestion Controlを適用できる。
  • unreliableと reliableなフローを多重化できることでポート番号や転送パケット数を節約できる。
SPEC
  • 新しい chunk type: Forward TSN chunkを追加する。
    Peerに対して、新しい cumulatie TSN pointを伝える。このchunkを受信した reciverは、指定されたTSN以前の、もしくは等しいTSNに関しては、データが正しく受信されたものとみなし、データの受信に関する報告を行なってはいけない。
  • INITと INIT ACKに、Parameter: Forward-TSN-Supportedを追加する。
    Peerに対して、Forward-TSN chunkをサポートしていることを伝える。
注意すべき点
  • abandonedなデータを partial_bytes_ackedに含めてはいけないし、cwndの計算に含めてもいけない
  • メッセージの一部に abandonedなデータが含まれる場合、メッセージ全体が abandonedになる。
  • senderがSACK block中の情報によって、Advanced.Peer.Ack.Pointを更新した場合は必ず FORWARD TSNを転送し、更新されたAdvanced.Peer.Ack.Pointの値を通知しなければならない。
  • receiver側が Forward TSNを受信し、TSNを skipさせた後に、その TSN持つ セグメントを受信した場合、duplicate dataと同様に扱う。




I-Ds



Architecture of Mobile SCTP for IP Mobility Support
mobile SCTP(mSCTP or ADDIP extension )のアーキテクチャを解説したもの。

mSCTPはserverがfixed addressを持つ client-server型のサービスに向いている。 (mobile node側からセッションが開始されるので)
peer-to-peerの通信モデルでは、MIPやSIPやRSerPool、DDNSを利用する必要がある。 (mobile nodeの location managementが必要)

MIPと異なり、SCTPの Handoverはルータに依存しない方法で実現できる。
SCTPは基本specで、マルチホームの機能を持つが、ADDIP extentionを利用することに より、アソシエーションの最中に IPアドレスを変更できる。 mSCTPを利用する場合は、fix node->mobile nodeのセッションは MIPなどのサポート が必要になるため、現状では mSCTPの手法は mobile->fixのセッションのみをターゲットとしている。

mobile->fixのコネクションでは、mobile clientがネットワーク間を移動した際に、 新たに取得したIPアドレスをASCONF chunkで fix nodeに通知し、その後新しいアドレス をPrimary Addressに変更する。mobileノード側の outgoing bufferに古いIPアドレス をソースアドレスにしたパケットが存在する場合のパケットの扱いは今後の課題。 mobile nodeが移動後、古いアドレスが inactiveになった場合、mobile nodeは古い アドレスをアドレスリストから削除しなければならない。


mSCTP with Mobile IP for Transport Layer Mobility
mSCTPと MIPを利用した seamless handoverの方法について説明したもの。

MIPだけを利用した handoverと mSCTPを用いた handoverでは、MIPのみの 手法が routerのサポートを必要とするのに対し、mSCTP+MIPでは transport layerで handoverを実現するため routerのサポートがいらない点が異なる。 (MIPは location Managementにのみ利用される)

現時点では、MIP+mSCTPの手法は CNからMNへと確立されたセッションのみを想定 している。MNからCNへと確立されたセッションは、mSCTPのみで handoverを実現できる。 つまり、CNは MNの位置を MIPを使って調べて sessionを開始する。MIPのデータ 転送に関する機能は mSCTP + MIPでは使われない。HoAはlocation managementだけに 利用されデータ転送には用いられない。

mSCTP + MIPでセッションをCNからMNへ開始する場合、CNはまずMIPを利用しMNまで INIT chunkを送信する。INIT chunkを受信したMNは CCoA(IPv4の場合)、CoA(IPv6の場合)を用いて INIT ACKを返信する。 MIPv4で CoAを利用して associationを確立するのはfuther studty.

MNが送信する INIT ACK chunkは、CCoA(IPv4)または CoA(IPv6)を Primary Addressとして送信し、同時に HoAも送信する。この HoAは CNが正しい MNから INIT ACK chunkを受信したことを検証するためだけに利用される。 以後の handoverは通常の mSCTPの手順で行われる。

    MIP only と mSCTP + MIPの違い
  • mSCTP + MIPの場合アプリは CoAを bindする必要がある。
  • route optimizationが必要なくなる。
  • HoA宛の転送を backup routeとして使えるかもしれない。


Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
SCTPのセッション中で利用できる IP addressを reconfigureする拡張について 説明したもの。

想定されるアプリケーション
  • 物理的にネットワークカードを追加、削除できるプラットフォーム。
  • multihome環境で、primaryアドレスを変更する場合
この拡張は、ASCONFと ASCONF-ACKの２つの新しい chunkタイプを定義し、 INIT/INIT-ACKと ASCONF/ASCONF-ACKで利用できる６つのパラメータを追加する。
ASCONF chunkは outstandingな ASCONFが存在しない場合のみ送信できる。
ASCONF-ACK中にレスポンスがない TLV parameterに関しては requestが成功 したものとみなす。したがってもし ASCON-ACK中にレスポンスが１つもなければ すべてのリクエストが成功したものとみなす。
ASCONF/ASCONF-ACK chunkは別のtypeの chunkと一緒に転送できる。


IP addressを追加できる機能は、セッションのhijackを容易にする可能性がある。 高いセキュリティが必要な場合、IP Authを利用すべきである。hijackの可能性は この extentionの有無に係わらず、core specの中にも存在する。


Multihoming issues in the Stream Control Transmission Protocol
SCTPの multihome issueについて解説したもの。

SCTPで通信する２つのノードが、それぞれ２つの IPアドレスを用いて 通信する場合を想定する。この時、SCTPの構成する２つの通信経路が 完全に独立していたとしても、一方のノードのルーティングテーブル の内容によっては、通信経路上の１リンクの異常により、SCTP assosiation全体が 通信できなくなってしまう場合がある。

この様な問題に対処するために、SCTPは tranportを sourceと destination address の pairで識別することが重要。
エンドノードが１つしかインターフェースを持たない場合でも、２つのアドレスを assignすることにより、pathに冗長性を持たすことができる場合がある。
NATを利用する場合、複数の endpointの IPアドレスに対応する global addressを 持つ必要がある。
IPsecは、multihome環境を考慮してデザインされていないので、SCTPの multihome 機能を IPsecと共に利用する場合にはいくつかの問題がある。例えば、IKEは 単一のsrcと dstアドレスの pairしかサポートしていない。この場合、src address とdst addressのすべての組合せに対して、SAを作る必要が生じる。



Mobile SCTP
SCTPによる seamless mobilityの実現について解説している。

SCTPで mobilityを実現するためには、mobile node側に SCTP Dynamic Address Reconfigurationの拡張を実装する必要がある。
スムーズな handoverを実現するためには、mobile nodeが複数のアクセス ポイントに同時にアクセスでき、かつ各アクセスポイントのシグナル強度を チェックできる機能がある事が望ましい。




back