一時間以上家を離れるとメールサーバがダウンする問題

自宅で運用されるメールサーバ

「WebとDNSとメールは自分で運用しなさい」「仕事で運用しているものを自宅で運用してはいけない」という教義に基づいて、我が家ではmacOSをサーバとしてWeb/DNS/メールを運用している。

このサーバにはMac Miniを使用しHeadless (ディスプレイを繋がない状態)で運用しているが、筐体が古くmacOSのサポート対象外となり、macportsの依存関係も壊れ始めていたため、Gmailのスパム対応強化の対応のためのメールサーバのDKIM導入を機に、重い腰を上げて新しく買って１年ほど放置していたM1 Mac Mini + macOS Sonomaに式年遷宮を試みた。

いくつかのトラブルはあったが、DNSとメールを新しいMac Miniに移行して、無事に運用を開始することができた。

新しいMac Mini (上)と古いMac Mini (下)

新しいMac Mini (上)と古いMac Mini (下)

いつのまにか無応答になっているメールサーバ

運用を開始していつかのタイミングからなぜかメールがセカンダリのサーバに届くようになってしまった。プライマリのMac Miniのメール関連のプロセスが死んだのかと思いトラブルシュートをしようとSSHを試みるも反応なし。pingにも応答なし。OSごとダウンしたと思い電源ボタン長押しで再起動をかけた。

何度かこの事象が発生しその都度ハードリブートをかけていたが、このままでは困るので時間を取って調査を開始した。

しかし system.log を見ても、mailのログを見ても、プロセスやOSがクラッシュした形跡はなく、何も分からなかった。

家を離れて１時間するとダウンするメールサーバ？

どのタイミングでセカンダリに切り替わったのかを調べることにした。これには何時のメールからセカンダリに届いたかを調べれば簡単にわかる。

直近は水曜日の17:30ごろ。この日は17:30から外部で講演の仕事があったため16:30に家を出た日。

その前は火曜日の9:00ごろ。この日は新しく着任されるチームメンバーを迎えるために8:00に出勤した日。

その前は…と調べていくと、どうやらPCを持って家を離れて１時間後にメールサーバがセカンダリに切り替わっているらしいことがわかった。そして30分程度で戻ってくる場合には切り替わりが起こっていないこともわかった。

 

どうやら一時間以上家を離れるとサーバがダウンしてしまうらしい。

 

………寂しくて死んでまうんか？？？

 

トラブルシュート開始

このMac MiniサーバはONUの位置関係上の制約でリビングでHeadlessモードで運用しており、ディスプレイを持ってきてつなぐのがちょっと面倒だったのでいままでハードウェアリブートする運用で対処をおこなっていたが、時間を取ってちゃんとトラブルシュートすることにした。

同様の事象が発生したタイミングでハードリブートは行わずにHDMIディスプレイを繋いでみた。画面は真っ暗。OSが落ちているのであれば期待通り。

次にキーボードとトラックパッドをBluetoothで接続してみた。すぐに反応はなかったが、トラックパッドを叩いていると画面が復活した。

 

……もしかしてSleepしていた…？

 

解決へ

SettingsでSleep周りの設定を確認したところ、Settings > Lock Screen の Turn display off when inactive が For 1 hour になっていた。これが１時間の原因。

Settings > Lock Screen

Settings > Lock Screen

つぎに Settings > Energy Saver を確認すると Prevent automatic sleeping when the display is off が disable になっていた（画像はenableしたあとのもの）

Settings > Energy Saver

Settings > Energy Saver

なんで家にいる間にこれが発動しなかったのかを振り返ってみると、家でPCを使っている間はMac MiniサーバにScreen Sharingで画面に接続していたからであった。

そのためPCを持たずに外出したときも問題は起こらなかったし、PCを持って外出しても1時間以内に帰ってきたときは、自動的にScreen Sharingが再接続をするので問題は起こらなかった。

 

PCを持って家を出て一時間経過したときだけ、自動的にディスプレイがオフになり、OSがスリープモードに入り、メールサーバがダウンしていたのだった。

 

わかってみればなんてことのない問題だった。

 

ちなみに古いMac MiniではEnergy SaverでSleepの設定をすべてNeverにしていた。

古いMac MiniのEnergy Saverの設定

教訓

macOSでサーバを運用するときは Prevent automatic sleeping when the display is off を有効化しましょう。

ブコメ返し

本筋とは外れるけどMacでメールサーバーを作って運用してはるのってかなりハードルが高いと思う(むかしMacbook+Postfixで挑戦したけど面倒で挫折した) - azumakuniyuki のブックマーク / はてなブックマーク

LinuxともBSDとも勝手が違うし情報もそこまで多くないのでハードルは高いですねー（わかってくれる人がいて嬉しい）。

macOSで運用してるのも仕事で運用してないものを使う教義の一貫なのかな - sora_h のブックマーク / はてなブックマーク

Yesです。LinuxはRHELベースとDebianベースと両方やっているので、プライマリがmacOS、セカンダリがFreeBSDです。あとmacOSはTime Machineがあるのでバックアップがすごい楽なのが気に入ってます。

Webは自分で運用する教義でも、blogははてなでいいのでしょうか? - kazuau のブックマーク / はてなブックマーク

いい質問ですね。自分のサーバだと検索エンジンのSEO的に不利な点が多すぎる（＆そこに頑張りたくなかった）のでブログについてははてなを利用しています。Webはプロフィールぐらいしか載ってません。

夜中おちなかったのかな？ - GARAPON のブックマーク / はてなブックマーク

はい、PC(MacBook Pro)をScreen Sharing立ち上げたままつけっぱだったので落ちませんでした。

この手の新ネタを見るたび、「500マイル」と「バニラアイス」と「中国茶」のエピソードとしての強さが際立つ。 - six13 のブックマーク / はてなブックマーク

ほんまね。でもそんなおもろいやつそうそう起きひんって。

電気代かかるからやらない - mayumayu_nimolove のブックマーク / はてなブックマーク

すんません。M1になったのでちょっとマシになるはず…

KDDIの通話・通信障害メモ

この記事は7/3午前中に記載したもので、まだKDDI社長の会見内容を反映していません。

今回のKDDIの障害が具体的にどういうサービスに影響が出るのものか、モバイルネットワーク初心者としてLTE/EPC/IMS周りの挙動の勉強のためにまとめてみた。

はじめにまとめ

モバイルの通信には音声通話とデータ通信があり、今回主に長時間の障害を受けたのは音声通話(IMS)の方だった。

7/2(土)の日中帯はデータ通信はできるが音声通話やそれに付属するサービスが利用できない状態が継続していた。データ通信も不安定な状態になっていた。

端末の実装(主にAndroid端末)によっては音声通話ができないとデータ通信も止めてしまう挙動があった。これによりLTEを回線として使用しAndroidベースで構築された決済システムなどが利用不可能な状態が継続した。

音声通話(IMS)が利用できないと、通常の電話はもちろん、緊急通報、SMS、位置情報の送信などの機能が利用できなくなる。IMSに依存しているキッズ携帯の機能が全滅して防犯上の課題も生じていた。

サービスの状況

  • 7/2未明の障害発生時は音声通話とデータ通信の両方ができなかった
  • 7/2 7時ごろにデータ通信が一部回復
  • 7/2 午前中には圏外表示を繰り返すようになり不安定
  • 以降データ通信も時々不安定になる状態が
  • auの携帯電話に通話すると「現在使われておりません」となる

端末による挙動の違い

音声通話は使用できないがデータ通信は可能なので外出時もLINE等は利用可能かと思われたが AndroidとiPhoneでIMS障害時のデータ通信の挙動が違うらしいことがわかった。

  • iPhone
    • アンテナピクトは立っていないがデータ通信は可能であった
      • ハンドオーバーしたときに時々データ通信もできなくなることがあった(4G表示が消える)ので完璧に通信可能というわけではなかった模様
  • Android
    • データ通信も利用不可能であった
      • IMS Registrationが通らないとデータ通信も実行しないような挙動になっているように見える
      • [追記] 実際にはメーカ端末・ファームウェア依存であり、すべてのAndroid端末がデータ通信不能だったわけではなく、OPPOの端末ではデータ通信可能だった報告がある
  • データカード
    • データ通信専用なので通常通り利用可能であったようだ

3Gへのフォールバックができない

VoLTEのIMS障害なのでVoLTEをオフにすれば3Gにフォールバックして使用可能になるかと思われたが、KDDIは3月末に3Gのサービスを終了していたので3Gにフォールバックできなかった。

5G SAは一部の法人ユーザに提供開始していたが、コンシュマー向けにはこの夏提供開始予定だった。

そのため3Gにも5Gにも切り替えることができず、ユーザ端末側からはどうしようもなかった。

www.kddi.com

追記

auのLTEは3Gと完全に切り離されているのでほとんどの端末ではどのみちフォールバックできないとのこと。

障害箇所の推測

  • 端末の挙動を見る限りIMS Registrationに失敗している模様
    • P-CSCFから先のI-SCSF、S-CSCF、HSSあたりでなにかあったんじゃないかと思われる
  • [追記] 7/2日中帯ではIMSにつながるPGWとのセッション確立失敗が見えていたとのこと
    • これにより前述のIMS Registrationが失敗したり、データ通信も不安定になっていたのだと推測される
    • この事象を解決するタイミングで輻輳が開始した模様
  • KDDIからもVoLTEの交換機故障による輻輳とアナウンスがあったのでIMSの障害で確定
  • おそらく何かをトリガーにしてUEが一斉にVoLTEのIMS Registrationを一斉に送り始めて、CSCF以降のIMSでコントロールプレーンの輻輳(キャパシティを上回る要求)が発生した可能性が高い
  • 他社携帯から架電すると「現在使われておりません」となるので、単なるP-CSCFの輻輳ではなくHSSあたりまでR/W負荷が集中して加入者情報の一貫性の喪失のような異常が起こっているのではないかと思われる
  • 全国的に影響が出ていることからもP-CSCFのようなフロントエンドの輻輳ではなくHSSのようなバックエンド側で異常が起きてるように思われる

 

エンドユーザへの影響

IMSが落ちたときにエンドユーザに対してどのような形で影響が出たのかを整理してみる。社会的な影響はpiyokangoさんがまとめてくれているので、技術的観点から。

piyolog.hatenadiary.jp

緊急通報

緊急通報の発呼フローの中にIMS Registrationが含まれているため、IMSに接続できなくなると110や119への緊急通報も発呼できなくなる。

実際に登山中に転落された方がauだったために通報できない事例が発生した。

緊急通報を取り扱う音声伝送役務は１時間または３万人を超えたら総務省の障害報告基準に当たるので、一発アウトだったと思われる。

障害報告

SMS

SMSにはSMS over IMSとSMS over SGsがあるが、KDDIの一般的なスマートフォンでサポートしているのはSMS over IMSであったため、SMSもほぼ利用不可能になっていたと思われる。

SMSが利用不可能になったことにより、SMSログインやSMSによる二要素認証などのSMSに依存したシステムが使用不能になる。特に自社の公衆Wi-Fiの認証に自社のSMSを使ってしまうとこのような障害のときに困ることがわかった。

  • Yahoo!JapanのSMSログイン
  • au Wi-Fi SPOTのSMSログイン
  • Amazonの二要素認証
  • クレジットカード会社や銀行のSMS認証

位置情報

端末の位置情報もIMSで送信されるため、IMSによる位置情報の収集・利用ができなくなる。IMS経由の位置情報に依存しているシステムは後述するキッズ携帯がある。

一方でバスのロケーションシステムはGPSで得た情報をデータ通信で送信していることが多いため、IMSには関係がなく利用できるはずだが影響が出ていた。影響を受けたシステムはAndroidベースの端末になっていてIMS障害の影響でデータ通信もできていなかった可能性が高い。

ICカード決済やクレジットカード決済

バスなどの移動体や自動販売機や精算機でICカードやクレジットカードの決済ができなくなった模様。LTE回線を使用してデータ通信で実装されていることが多いので、これらのシステムはAndroidベースで実装されており、IMS障害にデータ通信も巻き込まれた可能性が高い。

https://twitter.com/clouded19/status/1543428565143658497?s=20&t=0TT7M_kzIFMfxaBLg28-4g

キッズ携帯

個人的にはこれが一番ヤバそう。キッズ携帯はデータ通信がなくてIMSのみを使用しているため機能が全滅する。

通話ができない、SMSが送れない、位置情報確認ができないことによって、防犯ブザーがなったときの自動通話や、写真・位置情報の送信ができなくなるなどの防犯機能がほぼ無効化されてしまう。

IMSが落ちている時は子供を一人で外出させないなどの対応が必要になりそうだが、子供が学校に行っているときなどの日中帯に障害が起きたときには防ぎようがない。

  • 通話できない
  • SMSできない
  • 位置情報確認（安心ナビ）できない
  • 防犯ブザー発動時の位置情報送信・SMS通知が機能しない

IMSがダウンしても大丈夫な機能

緊急地震速報

緊急地震速報はETWSなのでIMSがダウンしても大丈夫。 LTEなETWSではCBCからMME、eNB経由でUEに送信される。今回はMMEに障害はなかったのでセーフ。

 

仕様・プロトコル

LTEのIMS

SIP/VoIP Security Audit | Solutions & Services | NextGen, Inc.

IMS Registration

IMS Registrationができなくて通話・通信ができないという話をしてきたが、この手順のフローは１ページに書けないぐらい長い。ざっくりのステップが以下の５つであるが、端末であるUEの他にP-CSCF、I-CSCF、S-CSCF、HSSという４つのプロバイダ側の設備（ネットワークファンクション）が連携して動作する。

どの設備がどこにどれだけの数配置されていて、どれだけの性能・キャパシティを持っていて、といったことを考え始めると今回の「輻輳」といったものに対処することがいかに難しいのかは想像しやすいと思う。

(1) GPRS Attach: The terminal registers to the GPRS Network.
(2) PDP Context Activation: An IP address is assigned to the terminal.
(3) Unauthenticated IMS Registration Attempt: The terminal attempts an IMS registration but is challenged by the IMS network to authenticate itself.
(4) IPSec Security Association Establishment: The terminal establishes a protected session with the IMS network.
(5) Authenticated IMS Registration: Registration is reattempted. This time the terminal is successfully authenticated and accepted.

以下の画像はIMS Registration Flowの４ページ中の２ページ目だけ抜粋したものである。

https://www.eventhelix.com/ims/registration/ims_registration.pdf

ETWS

LTEにおけるETWSではCBEが要求を出してCBCからMME、eNB経由でUEに送信される。このためIMSの障害の影響を受けない。一方的に情報を送るだけのシステムなので簡素化できている。

https://www.docomo.ne.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol17_3/vol17_3_021jp.pdf

 

その他情報が分かり次第&勉強でき次第随時追記・加筆修正します。

https://twitter.com/omusubi5g/status/1543205131239321600?s=20&t=P05NemvKgsih4NdvWEWWww

https://twitter.com/maganori/status/1543022606659768320?s=20&t=P05NemvKgsih4NdvWEWWww

RFC8986 Segment Routing over IPv6 (SRv6) Network Programming

SRv6 RFC翻訳

RFC8986 Segment Routing over IPv6 (SRv6) Network Programming

はじめに

この文書は RFC8986 Segment Routing over IPv6 (SRv6) Network Programming の翻訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献、RFC2119のやつ等は省略しています。

この文書はドラフトであるため、用語や表記が統一されていなかったり、仕様の内容について曖昧な部分がありますが、原文に忠実になるように訳しています。

免責

この翻訳を信用して不利益を被っても責任取れません的なやつ。

目次

  • はじめに
    • 免責
  • 目次
  • 概要
  • 1. はじめに
  • 2. 用語
  • 3. SRv6 SID
    • 3.1. SIDフォーマット
    • 3.2. SRドメイン内でのSID割り振り
    • 3.3. SID到達性
  • 4. SR Endpoint Behavior
    • 4.1. End: エンドポイント
      • 4.1.1. Upper-Layerヘッダ
    • 4.2. End.X: L3クロスコネクト
    • 4.3. End.T: 特定のIPv6テーブルのルックアップ
    • 4.4. End.DX6: カプセル化解除とIPv6クロスコネクト
    • 4.5. End.DX4: カプセル化解除とIPv4クロスコネクト
    • 4.6. End.DT6: カプセル化の解除と特定のIPv6テーブルのルックアップ
    • 4.7. End.DT4: カプセル化の解除と特定のIPv4テーブルのルックアップ
    • 4.7. End.DT46: カプセル化の解除と特定のIPテーブルのルックアップ
    • 4.9. End.DX2: カプセル化解除とL2クロスコネクト
    • 4.10. End.DX2V: カプセル化解除とVLAN L2テーブルルックアップ
    • 4.11. End.DT2U: カプセル化解除とユニキャストMAC L2テーブルルックアップ
    • 4.13. End.B6.Envaps: カプセル化を伴うSRv6 Policyに紐付けられたエンドポイント
    • 4.16. Flavor
      • 4.16.1. PSP: SRHのPenultimate Segment Pop
      • 4.16.2. USP: SRHのUltimate Segment Pop
      • 4.16.3. USD: Ultimate Segment Decapsulation
  • 5. SR Policy Headend Behavior
    • 5.1. H.Encaps: SRポリシーにカプセル化されるSR Headend
    • 5.2. H.Encaps.Red: Reduced Encapsulationを行うH.Encaps
    • 5.3. H.Encaps.L2: 受信したL2フレームに適用するH.Encaps
    • 5.4. H.Encaps.L2.Red: 受信したL2フレームに適用するH.Encaps.Red
  • 6. カウンター
  • 7. フローベースのハッシュ計算
  • 8. コントロールプレーン
    • 8.1. IGP
    • 8.2. BGP-LS
    • 8.3. BGP IP/VPN/EVPN
    • 8.4. まとめ
  • 9. セキュリティに関する考察
  • 10. IANAに関する考察
  • 11. 参考文献
続きを読む

RFC9136 IP Prefix Advertisement in Ethernet VPN (EVPN)

BGP Datacenter EVPN RFC翻訳

はじめに

この文書は RFC9136 IP Prefix Advertisement in Ethernet VPN (EVPN) の翻訳です。この文書ではEVPNのRoute Type 5 (IP Prefix)とサブネット間転送のための利用方法とユースケースの例が記述されています。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献、RFC2119のやつ等は省略しています。

この文書はドラフトであるため、用語や表記が統一されていなかったり、仕様の内容について曖昧な部分がありますが、原文に忠実になるように訳しています。

免責

この翻訳を信用して不利益を被っても責任取れません的なやつ。

draft-ietf-bess-evpn-prefix-advertisement-11からの差分

基本的にはRFC化にあたっての参照先の最新化や用語の一貫性保持のための修正が行われているだけで、技術的な内容についての差分はありません。

  • RFCの参照先の変更
    • EVPN-INTERSUBNETがRFC9135に
    • RFC5512がRFC9012に
  • 表記の統一

目次

続きを読む

ソフトバンク株式会社でモバイルネットワークで5GとかSRv6とかやっていきます

f:id:yuyarin:20211001180819j:plain

TL;DR

2021年10月1日からソフトバンク株式会社にITインフラアーキテクトとして入社し、モバイルコア向けのクラウド基盤をやっていきます。まずは得意分野の仮想基盤のネットワークを中心に活動して最終的にはソフトバンクのネットワーク全体に目を向けられるようになりたいなと思います。

これに伴いまして2021年9月末で新卒から10年半お世話になったNTTコミュニケーションズを退職いたしました。職場の皆様からは次のチャレンジを応援して温かく送り出していただきました。最高のチームでとても愛着のあるサービスでした。今までありがとうございました。

時間がない人のための一問一答

Q. なんで転職したの？

いきなり一言で答えられないので動機が強い順で書くと

  • 80歳まで働かざるをえない世界に備えて5年後10年後を考えたキャリアパスを考えようと思った
  • 前職でスペシャリストとして再就職したときにコミットしていたプロジェクトが一区切りついた
  • 前職のチームもサービスも最高の状態で僕が辞めても大丈夫だと自信を持てた
    次にやりたい技術があった
  • 今の環境がコンフォートゾーンに入っているなと感じた
  • NTT以外の会社で働いてみたかった
  • 転職を経験しておいたほうが良いと思った
  • 居座り続けると後輩の成長機会を奪うことになると思った

Q. なんでモバイル？

こんなにたくさん使われているのに僕が理解してない通信インフラがあるなんてけしからんと思ったから

Q. なんで5G？

まわりがみんな5GCの話をしていてけまらしかったから

Q. なんでSRv6？

まわりがみんなSRv6の話をしていてけまらしかったから

Q. なんでソフトバンク？

  • 超本気のラブコールをもらったから
  • SRv6を商用導入していたから
  • 元公社とは性質が正反対に見える「強い創業者の企業」で働いてみたかったから

Q. きっかけは？

f:id:yuyarin:20210930164900p:plain

友人のソフトウェアエンジニアが家を建てたので宅内ネットワークをローカル5GとSRv6にしようぜみたいな話をTwitterでやっていたら、ソフトバンクでSRv6と5Gに関わってるすごいエンジニアから「うちくる？」ってDMが飛んできたのでホイホイついていってしまった

Q. ITインフラアーキテクトってなにやんの？

モバイルテレコムクラウド基盤のアーキテクチャー策定と開発チームのリードをやるらしいけど、単にこの辺に応募してって言われて応募した職種のタイトルがこれだった感じです

Q. エンジニア？マネージャー？

部下なしのエンジニア（プロフェッショナル職）

Q. 給料あがった？

ベースの月収は下がってボーナス込みの年収の期待値は少し上がった感じ

Q. 他社は考えた？

3社から素敵なポジションにお誘いを頂いて3社とも内定を頂きました

Q. 他社のポジションは？

  • 外資系ネットワークサービスプロバイダのSRE職
  • 日系コンテンツプロバイダのSWE職
  • 日系コンテンツプロバイダのNWE職

Q. 他社の待遇は？

前職と同等かそれ以上

Q. 他社と比べてソフトバンクの待遇が良かった？

一概には比較できないけどベースは前職より下がってるし一番高い他社と比べたらかなりの差があるのでそうでもない

Q. じゃあなんでソフトバンク？

モバイルができるのが魅力的で抗えなかった

Q. 他社よりキツくない？（大企業的な自由度とか総務省案件とか）

だがそれがいい

Q. キャリアパスだいじょうぶ？

わかんねー

Q. そんなに給料上げてどうすんの？（前職の上司から訊かれた質問）

上げてるのは自分の給与ではなくて日本のネットワークエンジニアの給与だったり日本国民の平均所得なんだと思ってる

Q. NTT退職エントリ？

f:id:yuyarin:20211001085104p:plain

いいえ、退職したかったわけじゃなくて転職したら退職することになっただけで今のチームには感謝しか無いので特に退職にフォーカスを当てる気はないですhttps://twitter.com/u1/status/1067712835508039680?s=20

Q. ドコモじゃだめだったの？

だめじゃなかった

Q. じゃあなんでドコモに行かなかったの？

もともとモバイルの仕事をやる前提で転職しようとしていたわけではなかったので、内定先の中からソフトバンクに決めてからドコモに打診をするとタイミング的に合わなくなるから

Q. なんでNTTグループを出たかったの？

僕が感じていたことをタイミングよくDeNAの南場さんがズバッと言ってくれていたので引用します:

入社してから30年以上ずっと同じ会社しか見ていない人たちが集まって改革だ、イノベーションだって議論しているわけですが、さすがに無理があるように感じてしまいます。

business.nikkei.com

Q. 辞めると決めたときすっきりした？

むしろ最高の環境を捨てることがストレスになって盛大に肌荒れしたレベル

Q. NTTグループに戻ってくる可能性はある？

NTTコムであれば将来的に転職先の選択肢として十分に入るけどそのときにNTTコムが残ってるかはわからん

Q. 転職して後悔してない？

もう半年ぐらい遅らせておけばよかったなと思ってる…:

  • 住宅財形を解約する前に家を買っておけばよかった（非課税で継続できるか確認中）
  • ベース給与が下がる前に家を買って住宅ローンを組んでおけばよかった
  • プライベートで有給休暇が必要そうなタイミングで転職しなければよかった
  • 2年前の退職再就職時にお世話になった元上司の新しい職場でのミッションに貢献してから今のチームを離れればよかった

Q. 心残りは？

NTTグループ横断でエンジニアが集まってるSlackの在籍資格がなくなったこと

Q. 後任は？

前職の私のポジションの後任を募集していますので奮ってご応募ください（目安の値と違って実際は1000-1500ぐらい出ると思います）。

hrmos.co同じチームでエンジニアのポジションもありますのでこちらも是非ご応募ください（②がSDN寄りです）。

hrmos.co

Q. 一緒に仕事したいんだけど？

この辺に応募してください！

recruit.softbank.jp

さいごに

前職に向けてのメッセージ

Enterprise Cloud 2.0のSDNのチームに入って4年と2ヶ月でしたが、着任早々大障害が起きてその後もトラブルに見舞われ続けましたがなんとか安定させることができてSLAもいい感じの高い値を出すことができました。クラウドの開発チームはNTTコムの中では技術力的にもカルチャー的にもエンジニアにとって最高の環境で、僕のチームは最高のチームでした。あとはよろしくお願いします。ありがとうございました。また一緒に仕事しましょう。

f:id:yuyarin:20210930182628j:plain

現職に向けてのメッセージ

高く評価していただいて採用していただいてありがとうございました。今まで培ってきたインタードメインルーティングやデータセンターネットワーク・SDNなどのスキルと経験と成果を加味して将来性にベットしていただいたんじゃないかと思っていますので、皆様の期待に答えてリターンが出せるように精一杯頑張っていきたいと思います。これからよろしくお願いします！



IP Prefix Advertisement in EVPN (Draft 11)

BGP Datacenter EVPN Networking RFC翻訳

はじめに

この文書は IP Prefix Advertisement in EVPN (ドラフト11版) (draft-ietf-bess-evpn-prefix-advertisement-11) の翻訳です。この文書ではEVPNのRoute Type 5 (IP Prefix)とサブネット間転送のための利用方法とユースケースの例が記述されています。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献、RFC2119のやつ等は省略しています。

この文書はドラフトであるため、用語や表記が統一されていなかったり、仕様の内容について曖昧な部分がありますが、原文に忠実になるように訳しています。

免責

この翻訳を信用して不利益を被っても責任取れません的なやつ。

目次

続きを読む

QUICやHTTP/3で利用を避けるべき送信元ポートの議論についての考察

QUIC

f:id:yuyarin:20210722233918p:plain

https://www.slideshare.net/yuyarin/quicnat

最近QUICとNATについての話をJANOGで紹介するぐらいQUICという新しいプロトコルに既存のネットワークインフラがどう適応していくかを考えています。

id:asnokaze さんの記事で紹介されているように、QUICやHTTP3/3で送信元UDPポートとして利用を避けるべきポートの議論が行われています。これはUDPのリフレクション攻撃のへの対応としてインフラストラクチャ側で特定のUDPポートのトラフィックをブロックしているケースがあるからです。実際に私もこのブロックの設定を行ったことがあります。 これはUDPというプロトコルの特性に起因する問題であり、QUIC, HTTP/3に限らずUDPを使うプロトコルに広くある問題です。

asnokaze.hatenablog.com

QUICクライアント側で送信元ポートとして利用を避けた場合でもインフラストラクチャ側のミドルボックスによって避けるべきポートを送信元ポートとして使用されてしまう可能性があります。一番大きな障害となるのがIPv4 Source NATでしょう

この記事ではHTTP/3を提供する場合についてのみ考察します。この記事でHTTP/3に対して問題ないと判断しても、QUICを使用する別のまだ見ぬ新しいアプリケーションレイヤープロトコルでは問題が生じるかもしれません。

結論

結論から述べるとHTTP/3でサービスを提供する事業者が制御可能な範囲内でこの問題を回避することができます。ただし世の中には例外があり100%ではありませんが、おおよそ問題になることはないでしょう。

IPv4 Source NATとUDP増幅問題

IPv4 Source NAT(以下SNAT)では一般のNATでもCGN/LSNでもwell-knownポートを送信元ポートには使用しませんので、問題になるポート番号は1024 - 65535の範囲でUDP増幅攻撃に使用されるポートです。これに該当するポートを増幅率の順で並べると次のようになります。

問題になりそうなポートをUDPの増幅率で並べ替えると次のとおりです。増幅率はA10さんの資料を参考にしました。

ポート番号 プロトコル 増幅率 主な利用者
11211 memcached 10,000-51,000 コンテンツプロバイダ
27910 Quake 2 63.9 Eyeball/クラウド
1900 SSDP 30.8 Eyeball
1433 MSQL 25 エンタープライズ/クラウド
4672 Kad 16.3 Eyeball
27000-27030 Steam Protocol 5.5 Eyeball/コンテンツプロバイダ/クラウド
1024-65534 BitTorrent 3.8 Eyeball
5353 mDNS 2-10 Eyeball

本来であれば増幅率の他にプロトコルの普及率などで考える必要があります。個人的な感覚では危ないのは次の3つかなと思います。これはMLの元のリストのうちwell-knownポートのプロトコル以外のものと一致します。

ポート番号 プロトコル 増幅率 主な利用者
11211 memcached 10,000-51,000 コンテンツプロバイダ
1900 SSDP 30.8 Eyeball
5353 mDNS 2-10 Eyeball

memcachedはオンメモリのKey-Valueデータベースで主にコンテンツプロバイダなどのサービス提供側で使用されることが多いソフトウェアでありプロトコルです。UDP増幅攻撃においては非常に大きな増幅率を誇っており、一時期大きな問題になりました。

SSDPはUPnP(Universal Plug and Play)で使用されるプロトコルです。UPnPに対応している機器は家庭用ブロードバンドルータやプリンタなど主にEyeball側で利用される機器が多く、ターゲットもEyeball側になることが多いです。

mDNSは元々ローカルで提供されるサービスですが、一部の実装が外部からの問い合わせに応答してしまうことでUDP増幅攻撃に利用されています。

SNATで送信元ポートとしてこれらのポートを使うかどうか

結論から言うと使われる可能性があります。仕様として明確に禁止しているものがないため、実装や運用に依存します。

一般的なブロードバンドルータではそもそもSNATのエントリー数が数千と小さいため、エフェメラルポートの範囲で十分ですが、SOHO・中規模用のルータなどではSNATのポート範囲を1024まで拡張している場合があります。特定のポート番号についてそのポート番号を使用しないようにしている実装は稀だと思います（個人の感想）。

一番問題になるのがIPoEでのCGN/LSNの実装方式であるMAP-EなどのIPv6アドレスをIPv4アドレスとポート番号のレンジに静的にマッピングするタイプのSNATです。Subscriberあたり256個や512個のポート番号を連続した領域として割り当てるため、個別のポート番号だけを抜き取る実装はありません。そのポート番号を含むレンジをまるごと使用不可にすることは考えられますが、私の知る限りそのような実装はありません。

以降でこれらのポート番号が送信元ポート番号として使われたとしてもおそらく問題がないであろう(大きな問題にならないであろう)理由を述べます。

Eyeball側をターゲットとしたUDP増幅攻撃への対処

f:id:yuyarin:20210722233632p:plain

SSDPやmDNSはEyeball側の機器が増幅器になります。この攻撃を防ぐ箇所としては以下の8箇所が考えられます。これらのうち実際にブロックを行う可能性があるのは③か⑧です。

番号 場所 条件 ブロックするか
① ISPのIngress全般 送信元ポート しない
② ISPからSubscriberへのEgress 送信元ポート しない
③ SubscriverのIngress 送信元ポート しているかもしれない
④ SubscriverのEgress 宛先ポート しない
⑤ ISPのSubscriberからのIngress 宛先ポート しない
⑥ ISPのEgress 宛先ポート しない
⑦ ISPのSubscriberや顧客や子ASへのEgress 宛先ポート しない
⑧ Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない
⑨ Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない

③のケースではSubscriberのCPEにおいて送信元ポート番号をブロックするケースですが、設定している可能性はそれほど高くなく、また、設定していたとしてもSNATのinside側で行われているかと思うので、無害でしょう。

⑧のケースでは宛先ポートですのでブロッキングを行っていたとしてもQUICには影響がありません。

③と⑧以外の箇所では「しない」としていますが、ISPによってはブロッキングしている箇所がある可能性があります。基本的にポート番号によるブロッキングは通信の秘密を侵害することになります。OP25Bのように正当業務行為による違法性阻却事由が成り立つ場合は、これを根拠に実施しているISPはありえます。ここはどの程度のISPが実施しているかを調査する必要がありますが、それほど多くはないかと思います。

HTTP/3でサービスを提供する事業者になりえるのは⑧、クライアント側になりえるのが③や⑧と考えたときに、上記のことからEyeball側がターゲットになるSSDPやmDNSについては、QUICの送信元ポート番号がこれらのUDP増幅攻撃対策のためのブロッキングから影響を受ける可能性は低いと思います。

コンテンツプロバイダ側をターゲットにしたUDP増幅攻撃への対応

f:id:yuyarin:20210722233647p:plain

memcachedはコンテンツプロバイダ側の機器が増幅器になります。この攻撃を防ぐ箇所としては以下の8箇所が考えられます。これらのうち実際にブロックを行う可能性があるのは③と④と⑧と⑪です。

番号 場所 条件 ブロックするか
① ISPのIngress全般 送信元ポート しない
② ISPから法人顧客や子ASであるコンテンツプロバイダへのEgress 送信元ポート しない
③ コンテンツプロバイダのIngress 送信元ポート しているかもしれない
④ コンテンツプロバイダのEgress 宛先ポート しているかもしれない
⑤ ISPの法人顧客や子ASであるコンテンツプロバイダからのIngress 宛先ポート しない
⑥ ISPのEgress 宛先ポート しない
⑦ ISPのSubscriberや顧客や子ASへのEgress 宛先ポート しない
⑧ Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない
⑨ Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない
⑩ ISPのSubscriberからのIgress 送信元ポート しない
⑪ ISPのSubscriberのIgress 送信元ポート しているかもしれない

ISPでは基本的には法人顧客や子ASに対してトラフィックのブロッキングは行いません。

③も④もブロッキングを行っている可能性がありますがネットワーク外部の(例えばクラウドサービス上に立てた)memcachedにアクセスするためには必要なのでブロッキングしている可能性は低いです。③がクライアントからのHTTP/3のトラフィックに関係しますが、これはHTTP/3でサービスを提供する事業者側で制御可能な範囲なので対処可能です。

⑧はブロッキングしている可能性が高いです。これはmemcachedがUDP増幅攻撃に使用された場合の対処方法として、ネットワーク内部にmemcachedを立てている場合に信頼できるIPアドレス以外の外部からの宛先ポートが11211であるパケットを落とします。これはブロッキングを行っていてもHTTP/3には影響しません。

⑪はブロッキングされている可能性があります。これはEyeball側で内部でmemcachedがNW管理者の関知しない範囲で立てられていたときにUDP増幅攻撃に加担しないようにNW管理者側でブロックしているケースです。ただしこの場合もブロックはSNATを行う前に実施されるので、HTTP/3トラフィックに対する影響はありません。

HTTP/3でサービスを提供する事業者になりえるのは③、④、⑧ですが、いずれも影響がありません。

HTTP/3でサービスを提供するコンテンツプロバイダ側でできる対策

HTTP/3でサービスを提供しようとした場合に、UDP増幅攻撃の対処としてのブロッキングに影響を受けないためには以下の対応を行えば十分だと考えられます。

  • SNATされないケースを考えて、HTTP/3クライアント側で送信元ポート番号に増幅攻撃に利用されるポート番号を使用しない(現在のWGの方向)
  • 送信元ポート番号が11211であるトラフィックをブロックしているネットワークにHTTP/3のフロントエンドを設置しない(コンテンツ事業者の努力)
  • SNATが行われなくても済むようにIPv6でのサービスを提供する(コンテンツ事業者の努力)

というわけで今のWGの流れは方向性としては概ね正しいかと思います。

もう少し踏み込んで少しの可能性も潰したい場合、memcachedの11211のブロッキングを回避するためには、送信元ポート番号として偶数番号を使うことが対策になりえます。なぜならRFC4787にもあるように多くのSNATの実装ではPort Parityとして送信元ポート番号の偶奇を保つようにしているからです。ただし送信元ポート番号の枯渇が2倍速になる問題があります。

最後に

これらはあくまでコンテンツとEyeballと単純に分割して考察した場合です。コンテンツプロバイダやクラウドサービス同士でHTTP/3でAPI提供が行われた場合なども考察する必要があります。

いずれにせよ、新しいプロトコルの発展を阻害しないためにみんなで協力しあって頑張っていきたいところです。

考慮が足りない箇所があったら遠慮なくコメント欄か @yuyarin までお知らせください。