OpenDaylight 另一個Open Source SDN /NFV 整合計畫

在了解什麼是Opendaylight 計畫之前，要先了解幾個專有名詞 Software-Defined Networking (SDN)、Network functions Virtualization (NFV) 和 Network Virtualization (NV)，參考Which is Better – SDN or NFV 這篇文章：

SDN – separates the network’s control (brains) and forwarding (muscle) planes and provides a centralized view of the distributed network for more efficient orchestration and automation of network services.

NFV – focuses on optimizing the network services themselves. NFV decouples the network functions, such as DNS, Caching, etc., from proprietary hardware appliances, so they can run in software to accelerate service innovation and provisioning, particularly within service provider environments.

NV – ensures the network can integrate with and support the demands of virtualized architectures, particularly those with multi-tenancy requirements.

Vmware 的新策略 vCloud and VxLAN

圖片來源：vCloud

趁著過年把之前的筆記整理整理，延續 [筆記] Software Define Network (SDN) 的歷史緣由這篇，在那場演講中有一個案例特別引起我的興趣，也就是VMware的新方向。

What is vCloud?

VMware 近幾年來腹背受敵，在Private Cloud 領域被後進者(如Citrix 的XenServer 、Microsoft 的 HyperV 、Redhat 的 KVM...等)用足夠的功能及便宜的價格不斷的在挖牆角，而在Public Cloud 的領域又備受AWS 的競爭(更不用說Google Cloud Platform 以及 Microsoft Azure)，到底VMware該怎麼走出他的困境呢？

於是我們看到了VMware提出了新的Business Model - VMware vCloud® Hybrid Service™, built on VMware vSphere®, quickly and seamlessly extends your data center into the cloud using the tools and processes you already have. 這個Business Model 所要解決的問題是VM搬移的問題。

因為目前的IaaS大廠如AWS 目前的缺點就是VM只能Run 在他們的data center 裡面(雖說最近AWS 終於開放VM Import/Export 的功能，但是也只能Offline搬移)，而VMWare 的Niche 就是就是可以提供Hybrid cloud的功能，當你在你的Private cloud 使用量不夠的時候，就直接從Private cloud 直接移動到VMWare 的 Public  cloud (只要你的Private Cloud 也是用VMware Solution)。

因此VMware 開始建造自己的IaaS - vCloud，而且由VMware來建Cloud也有一個優點，既然是用自家的技術，比起其他嘗試用VMware當IaaS的廠商就少了VMware 高License 費用的問題(HiCloud 表示...:P)

MPTCP (Multi-path TCP)

圖片：MCTCP

Multi-path TCP 

前一陣子聽到Citrix 來介紹他們的產品，其中特別強調到Netscaler有提供MPTCP的支援，而且iOS 7 現在也都支援MPTCP，所以公司內部應該有提供這樣的設備...不拉不拉，此外電信商知道他的3G網路頻寬不夠，所以會希望你多用WIFI，所以像中華電信就有提供利用Sim卡的認證機制，讓使用者的Iphone偵測到有WIFI時可以自動登入，這就讓我好奇了，到底什麼是MPTCP？

簡單來說 MPTCP 就是提供無間斷的Romaing的Protocal，根據wiki解說的好處：

The redundancy offered by Multipath TCP enables inverse multiplexing of resources, and thus increases TCP throughput to the sum of all available link-level channels instead of using a single one as required by plain TCP. Multipath TCP is backwards compatible with plain TCP.
Multipath TCP is particularly useful in the context of wireless networks ^[1] - using both Wi-Fi and a mobile network is a typical use case. In addition to the gains in throughput from inverse multiplexing, links may be added or dropped as the user moves in or out of coverage without disrupting the end-to-end TCP connection.

也就是說如果 Wi-Fi 的連線品質不佳，甚至是斷線了，在以往，這次的資料傳輸作業，應該就得要重新來一次，現在運用 Multi-Path TCP 之後，Wi-Fi 的連線品質不佳時，系統會自動找比較目前理想的連線(如 3G)，繼續傳輸作業，不讓資料傳輸中斷。當然，在有 3G、Wi-Fi 與有線網路的電腦上，如果能運用這種技術，則連線品質將有所提高。



Reference:
[1] Maximize mobile user experience with NetScaler Multipath TCP
[2] Multi-Path TCP 讓您的網路連線品質更好

[筆記] NAT Traversal and Peer to Peer

Source: html5rocks

Cloud Computing 被翻成雲端運算，現在又被解讀成雲與端的整合 (其實還蠻貼切的)，最近又可以再擴大解釋成 - 雲與端、雲與雲、端與端之間的互動整合 (好像在勞口令)，像是Line和whatsapp 就是最好的例子，透過雲來協助端與端(手機與手機)之間的互動和溝通。

除了手機與手機之間的溝通，另一個應用就是物聯網(IOT)的概念，讓Device 與 Device 互相溝通，或是手機與Device 互相溝通。但是隨著端點(End Device)的種類越來越多，而端與端之間所處的網路環境也越來越複雜，這時就會遇到許多問題，其中NAT Traversal與穿越防火牆的問題，就是其中之一，還好再此之前傳統的P2P (IM、VoIP...等)相關應用領域就已經有相當多的解決方案和案例可以參考。

(把收集到的資料整理如下)

NAT穿透 (NAT traversal)

NAT穿越（NAT traversal）涉及TCP/IP網路中的一個常見問題，即在處於使用了NAT設備的私有TCP/IP網路中的主機之間建立連接的問題。

會遇到這個問題的通常是那些客戶端網路交互應用程序的開發人員，尤其是在對等網路和VoIP領域中。IPsec VPN客戶普遍使用NAT-T來達到使ESP包通過NAT的目的。

儘管有許多穿越NAT的技術，但沒有一項是完美的，這是因為NAT的行為是非標準化的。這些技術中的大多數都要求有一個公共伺服器，而且這個伺服器使用的是一個眾所周知的、從全球任何地方都能訪問得到的IP位址。一些方法僅在建立連接時需要使用這個伺服器，而其它的方法則通過這個伺服器中繼所有的數據——這就引入了頻寬開銷的問題。[0]

常用的NAT穿越技術就是下面兩者：

STUN

STUN全名 Simple Traversal of User Datagram Protocol through Network Address Translators (NATs)，(翻譯：NAT的UDP簡單穿越)，是一種網路協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種類型的NAT之後以及NAT為某一個本地埠所綁定的Internet端埠。這些信息被用來在兩個同時處於NAT 路由器之後的主機之間建立UDP通信。該協議由RFC 3489定義。[1]

TURN 

TURN（全名 Traversal Using Relay NAT），是一種資料傳輸協議(data-transfer protocol )。允許在TCP或UDP的連線上跨越 NAT 或防火牆。TURN是一個client-server協議。TURN的NAT穿透方法與STUN類 似，都是通過取得應用層中的公有地址達到NAT穿透。但實現TURN client的終端必須在通訊開始前與TURN server進行交互，並要求TURN server產生"relay port", 也就是relayed-transport-address。這時 TURN server會建立peer, 即遠端端點（remote endpoints）, 開始進行中繼（relay）的動作，TURN client利用relay port將資料傳送至peer, 再由peer轉傳到另一方的TURN client。[2]

ICE

互動式連接建立（Interactive Connectivity Establishment），一種綜合性的NAT穿越的技術。互動式連接建立是由IETF的MMUSIC工作組開發出來的一種framework，可整合各種NAT穿透技術，如STUN、TURN（Traversal Using Relay NAT，中繼NAT實現的穿透）、RSIP（Realm Specific IP，特定域IP）等。該framework可以讓SIP的客戶端利用各種NAT穿透方式打穿遠程的防火牆。 如果UDP傳送失敗，ICE會改試TCP： 先是 HTTP，然後改試 HTTPS。此外如果使用STUN (UDP)直接連線失敗，ICE會切換道TURN (relay模式)，ICE uses an intermediary (relay) TURN server。所以 ICE 其實就是混和TURN 和STUN的行為模式的通訊協定。 [3]

Java Open Source Library

• JStun only work for UDP , example    
• PJNATH 
• stund  
• stun4j 
• turnserver 
• ice4j

延伸閱讀：

• NAT Traversal, part 0 
• NAT Traversal, part 1 – NAT Behavior
• NAT Traversal, part 2 – STUN
• NAT Traversal, part 3 – TURN
• 穿越防火牆技術

Reference:

[0] WIKI - NAT Traversal
[1] WIKI - STUN
[2] WIKI -TURN
[3] WIKI - ICE

是否可以關閉SSH Tunneling 的加密或是降低加密等級

圖片來源：網路

大家一定覺得很奇怪，SSH的存在就是為了要有一個安全加密的通道啊，怎麼會有人想要關閉加密功能或是降低加密等級呢？怎麼會有這樣的需求呢？在解釋之前先來先舉幾個會用到SSH Tunneling 的正常案例：

• 情境一："反向建立 SSH Tunnel、免 VPN 連回公司"

• 情境二："Port Forwarding with SSH" 

所以建立SSH Tunnel的主要用意就是建立一個通道，想辦法可以由外界進入一個受限制的網路，看圖片比較有感覺。

圖片來源：網路

圖片來源：網路

由這張圖就可以看到，透過 SSH Tunnel 傳遞的資料都是有受到加密保護的，一直到離開SSH Tunneling 到達受限制的內網(相對起來也是受信任的內網)。

 圖片來源：網路

這時候問題來了：

1. 如果我要連線的Device (Embedded System) cpu 不夠力怎麼辦?是否可以關掉？
2. 加密對於速度也會有影響，那要如何增加速度呢？
3. 加密到底是用麼演算法在加密呢？

所以我在網路上找到幾個答案：

1. 有加密和沒加密速度可以差到86%

RFC 4253 specifies that, during handshake, client and
server can agree not to use any bulk encryption.
In other words, the encrypted transfer speed is *** 86% SLOWER ***
than the unencrypted transfer speed.

2. 透過patch 的方式：hpn-ssh ，的確可以關掉

3. 就是降低加密等級
---------------------------------------------------------------------------
You cannot disable encryption, at least not in any standards-compatible way. You can pick weaker and/or faster ciphers if you're really worried about overhead. ARCFour and Blowfish are pretty fast. DES is slow.

For OpenSSH:
man ssh_config
man sshd_config

The following ciphers are currently defined:

      3des-cbc         REQUIRED          three-key 3DES in CBC mode
      blowfish-cbc     OPTIONAL          Blowfish in CBC mode
      twofish256-cbc   OPTIONAL          Twofish in CBC mode,
                                         with a 256-bit key
      twofish-cbc      OPTIONAL          alias for "twofish256-cbc"
                                         (this is being retained
                                         for historical reasons)
      twofish192-cbc   OPTIONAL          Twofish with a 192-bit key
      twofish128-cbc   OPTIONAL          Twofish with a 128-bit key
      aes256-cbc       OPTIONAL          AES in CBC mode,
                                         with a 256-bit key
      aes192-cbc       OPTIONAL          AES with a 192-bit key
      aes128-cbc       RECOMMENDED       AES with a 128-bit key
      serpent256-cbc   OPTIONAL          Serpent in CBC mode, with
                                         a 256-bit key
      serpent192-cbc   OPTIONAL          Serpent with a 192-bit key
      serpent128-cbc   OPTIONAL          Serpent with a 128-bit key
      arcfour          OPTIONAL          the ARCFOUR stream cipher
                                         with a 128-bit key
      idea-cbc         OPTIONAL          IDEA in CBC mode
      cast128-cbc      OPTIONAL          CAST-128 in CBC mode
      none             OPTIONAL          no encryption; NOT RECOMMENDED
----------------------------------------------------------------

Reference:
[1] Disable encryption ssh