読者です 読者をやめる 読者になる 読者になる

LGTM

Looks Good To Me

JANOG35 に行ってきた (Day3)

networking

JANOG35 に行ってきた (Day2) に引き続き,JANOG35 レポート.

ほぼ毎回行ってるイベントで,インターネットに関するネットワーク寄りの知見を得られる.参加者はネットワークエンジニア中心.

気になったセッションをいくつか紹介しようと思う.

ところで,この日は駅からこんなバスで送迎してもらった.

すごい目立ってました...ご通行のかたも「なぜ!」ってなるわ. イベントのホストさん曰く「いや,たまたまバス会社が持ってたんです」なぜこんなの持ってる...

JANOG35会場ネットワークに関して

JANOG35 では,ホストさんとconbu プロジェクトに会場ネットワークを提供していただきました.すごく快適でした!ありがとうございました.

このセッションでは,会場ネットワークを設計 / 構築するにあたり conbu が何を目指して,どうネットワークを作ったかが紹介されている. 知見が溜まっているようで,興味があるひとは結構いそう.

やりたいこと

  • 会場側にすでにあるルーターは家庭用のものが多いが,トラブルの原因になりがち
    • NAT テーブルが小さい
    • 設定を変えられない
  • 会場に持ち込むハードウェアを少なくしたい

どうやったか

  • 会場からのtraffic を全部VPN でくるむ
    • 1つの大きな通信に見えるから,会場ルーターにやさしい
  • 他方のVPN 終端はクラウド環境 (物理かも?) にあって,そこからInternet に抜ける
  • サーバー類はすべてクラウド環境側に置く
    • DHCP,DNC,Wireless Controller,監視用サーバー...
    • 現地に持ち込むのは,Wireless AP / AP 用のSwitch / VPN 終端ルーターのみ

こうすることで「会場が変わっても,現地セットを持っていくだけで簡単に会場ネットワークが構築できるし,事前のテストも半日程度になる」とのこと.

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.
    

    https://tools.ietf.org/html/rfc5575

  • 経路の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 読んでなくて,現状どうなってるのか分かってません)

当世MVNO事情

MVNO 事業者 3社のサービス開発の裏側,ネットワークの紹介,トラブル事例,悩みごとの紹介.いわゆる「格安SIM」の裏側の話.

ネットワーク構成

  • MNO とL2 接続することが多い
    • 帯域制御など,付加価値をつけやすい
    • 他には回線卸,L3 接続がある
  • MVNO 事業者は,P-GW / GGSN / PCRF / PCEF を自社で運用
  • IIJ ではRCRF(DCCA) を内製

サービス全般

  • IIJmio だと,LTEIPv6 を使える端末がある
    • IPv6 利用率: 1.97%
  • MNO のtraffic ピークは夜だが,IIJmio のピークはランチタイム
  • MNO との棲み分けが今後のキモ
    • MVNO 同士の競争は終焉に向かっているように思える
  • 端末検証たいへん
    • iOS8 にしたら使えなくなった! とか
    • 降ってくるキャリアプロファイルの中身が事前に分からない
  • サービスのbackend を作るのが大変.あと交換機高い
  • MVNO 全体で,シェア1% とか
    • 欧米では10% ほど

感想

  • 3GPP 難しすぎる.3文字略語がまったく分からないレベル
  • MVNO 事業者 (一部MVNE もやってる) の苦悩がわかって興味深い

RPKIやってみませんか?

GREE のラボ環境でOrigin Validation をやってみた結果と課題の紹介.是非RPKI やってみよう! というメッセージ.

  • Validation を集中的に Route Reflector でやろうとしたが,できなかった
    • iBGP peer では動作しない
  • INVALID になってもログに残す機能がない
  • ルーターのリブート時の動作が気に入らない
  • ゴールはBGPSEC = Origin Validation + Path Validation
  • ルーターROA の正当性を確認できないので,信頼できるROA キャッシュとセキュアなトランスポートを使うべき
  • Origin Validation だけでは対処できない問題も起こっている
  • public ROA cache もあります
    • ROA キャッシュの位置について
      • IX にpublic なものがある.でも最終的には自社ネットワーク内に置くことが望ましい
  • JPNICROA 作成ツール作り込んでます!

感想

  • 簡単な設定で動くので,対応ルーターがあれば試してみると面白いと思う
    • ルーティングを変えずに 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 普及率がかなり高くないとダメなのでは

    • 最近の議論を追ってないので,間違えているかもしれません.その際にはご指摘いただけるとうれしいです
  • public ROA cache 統計情報

    • IPv4 10 セッション + IPv6 5 セッション ほど