JANOG35 に行ってきた (Day3)
JANOG35 に行ってきた (Day2) に引き続き，JANOG35 レポート．
ほぼ毎回行ってるイベントで，インターネットに関するネットワーク寄りの知見を得られる．参加者はネットワークエンジニア中心．
気になったセッションをいくつか紹介しようと思う．
ところで，この日は駅からこんなバスで送迎してもらった．
ロンドンバス！なぜ！ pic.twitter.com/sjKtfxyhuF
— K (@ponytail_68) January 16, 2015すごい目立ってました．．．ご通行のかたも「なぜ！」ってなるわ． イベントのホストさん曰く「いや，たまたまバス会社が持ってたんです」なぜこんなの持ってる．．．
JANOG35会場ネットワークに関して
JANOG35 では，ホストさんとconbu プロジェクトに会場ネットワークを提供していただきました．すごく快適でした！ありがとうございました．
このセッションでは，会場ネットワークを設計 / 構築するにあたり conbu が何を目指して，どうネットワークを作ったかが紹介されている． 知見が溜まっているようで，興味があるひとは結構いそう．
やりたいこと
- 会場側にすでにあるルーターは家庭用のものが多いが，トラブルの原因になりがち
- NAT テーブルが小さい
- 設定を変えられない
- 会場に持ち込むハードウェアを少なくしたい
どうやったか
- 会場からのtraffic を全部VPN でくるむ
- 1つの大きな通信に見えるから，会場ルーターにやさしい
- 他方のVPN 終端はクラウド環境 (物理かも？) にあって，そこからInternet に抜ける
- サーバー類はすべてクラウド環境側に置く
こうすることで「会場が変わっても，現地セットを持っていくだけで簡単に会場ネットワークが構築できるし，事前のテストも半日程度になる」とのこと．
conbu の背景
イベントが多い首都圏などでは，会場ネットワーク運営のニーズはかなりありそう． 「conbu ってなに？」という方には，JPA Thanks CONBU トークセッション のときのスライドをどうぞ．
BGP Flowspec(RFC5575)
タイトルから想像しづらいが，Arbor Networks が出しているDDoS トレンドレポート(ATLAS Q3 2014 DDoS Attack Trends みたいなやつ) を解説付きで説明してくれているので参考になる．
このセッションの主旨は「DDoS を止めるためにBGP Flowspec を使えるかも．なのであらためて紹介します」
感想
- RFC5575 自体はけっこう古くて，2009 年にpublish されたもの
- 私の印象ではあまり注目されてなかったのだが，なぜ今Flowspec を取り上げたのか気になった (が，聞くの忘れた)
セッション中では「Intra-AS ルーティングで使う想定」と言っていたが，RFC を読むとInter-AS もスコープ内に見える
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.経路のoriginator がFlowspec spec のoriginator である必要がありそう
A flow specification NLRI must be validated such that it is considered feasible if and only if: a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.https://tools.ietf.org/html/rfc5575#page-14
便利につかうために議論したいことはたくさんあって，たとえば
- Transit AS がFlowspec を追加 / 変更したい
- Flowspec NLRI を消す = 広報しないことはできそう
- 逆に，出したFlowspec をTransit AS に操作されたくない
- Flowspec を受け取った側が，ポリシーに応じてFlowspec をpermit / deny したい
のような要望がある気がする．(関連I-D 読んでなくて，現状どうなってるのか分かってません)
- Transit AS がFlowspec を追加 / 変更したい
当世MVNO事情
MVNO 事業者 3社のサービス開発の裏側，ネットワークの紹介，トラブル事例，悩みごとの紹介．いわゆる「格安SIM」の裏側の話．
- OCN Mobile One
- IIJmio
- mineo
ネットワーク構成
- MNO とL2 接続することが多い
- 帯域制御など，付加価値をつけやすい
- 他には回線卸，L3 接続がある
- MVNO 事業者は，P-GW / GGSN / PCRF / PCEF を自社で運用
- IIJ ではRCRF(DCCA) を内製
サービス全般
- IIJmio だと，LTE でIPv6 を使える端末がある
- IPv6 利用率: 1.97%
- MNO のtraffic ピークは夜だが，IIJmio のピークはランチタイム
- MNO との棲み分けが今後のキモ
- MVNO 同士の競争は終焉に向かっているように思える
- 端末検証たいへん
- iOS8 にしたら使えなくなった！ とか
- 降ってくるキャリアプロファイルの中身が事前に分からない
- サービスのbackend を作るのが大変．あと交換機高い
- MVNO 全体で，シェア1% とか
- 欧米では10% ほど
感想
RPKIやってみませんか?
GREE のラボ環境でOrigin Validation をやってみた結果と課題の紹介．是非RPKI やってみよう！ というメッセージ．
- Validation を集中的に Route Reflector でやろうとしたが，できなかった
- iBGP peer では動作しない
- INVALID になってもログに残す機能がない
- ルーターのリブート時の動作が気に入らない
- ゴールはBGPSEC = Origin Validation + Path Validation
- ルーターはROA の正当性を確認できないので，信頼できるROA キャッシュとセキュアなトランスポートを使うべき
- Origin Validation だけでは対処できない問題も起こっている
- bitcoin を不正に増やすためにroute hijack が使われた が，どうやら配下にAS を作ってhijack したっぽい
- Path Validation が必要なケース
- public ROA cache もあります
- ROA キャッシュの位置について
- IX にpublic なものがある．でも最終的には自社ネットワーク内に置くことが望ましい
- ROA キャッシュの位置について
- JPNIC でROA 作成ツール作り込んでます！
感想
- 簡単な設定で動くので，対応ルーターがあれば試してみると面白いと思う
- ルーティングを変えずに VALID / INVALID / UNKNOWN をマークするだけ，とか
- 中央集権的にvalidate できればいいけど，BGP でできるんだろうか…
- validate するだけなら，もちろんできる
- ルーティングに適用しようとすると，AS border では「INVALID な経路をreject しない」ってことだから そいつが使われる可能性あるんでは
- ルーティングに適用しようと思うとハードルが上がる
- AS border ルーターへの投資
- 第三者 (prefix オーナーやRIR / LIR など) の過失によるトラブル増 -> カスタマーサポートコスト
- DNSSEC と同じ構図
Path Validation で検証できるのは「その経路が AS_PATH どおりに伝搬してきたこと」だと理解してるんだけど，bitcoin のケースを検知するには「Path Validation できない経路をINVALID 判定」しないといけなくて，それはBGPSEC 普及率がかなり高くないとダメなのでは
- 最近の議論を追ってないので，間違えているかもしれません．その際にはご指摘いただけるとうれしいです
