5GCのOpenAPI定義からファイル間循環参照を取り除いてみた話

この記事はBBSakuraNetworksアドベントカレンダー2022の3日目の記事です。

こんにちは。BBSakura Networks株式会社の金井です。 5GコアネットワークのOpenAPI定義を調べていた際の課題について少し書きたいと思います。

5GコアネットワークのOpenAPIの辛いところ

モバイル網で実用化されている5Gのコアネットワーク(以降、5GC)のAPIのインタフェース定義にはOpenAPIが採用されています。 そのためプロトタイプ実装は容易にできると考えられがちです。しかし実際のところ手軽ではありません。 次の2つが大きな問題としてあります。

  • OpenAPI3の安定したオープンなコード生成ツールは見当たりません
  • JSONとHTTPだけではなく別のバイナリプロトコルが埋め込まれる箇所があります

これらとは別に循環参照があるとGoでコンパイルが通らない問題があります。今回はこの循環参照について書きたいと思います。

ためしに自作のデバッグツールで仕様ファイル間の依存関係を出力してみます。

5GCの仕様ファイル間の依存関係のグラフ
5GCの仕様ファイル間の依存関係のグラフ

あまりに大きな依存グラフなので切り抜きました。完全なグラフはGoogle ドライブに置きキャプションからリンクしています。 理解するのが大変そうですね。

では今回の流れです。

  1. 目的: OpenAPIのコード生成を使ってプロトタイプ実装をGoで手早く取り組みたい。
  2. 課題: 仕様ファイルに循環した依存関係があり、生成されるGoコードがコンパイルエラーとなる。
  3. 方針: 仕様ファイルに順序を入れて循環がなくなるようにスキーマ定義を移動する。
  4. 結果: 循環参照が解決しました。
  5. 後日談: OSSのコード生成ツールはバグが多く利用できません。

仕様の相互参照がなぜ困るのか

Goは循環依存するパッケージを許可しません。そのため循環参照を持つ仕様ファイルから単純にコード生成するとパッケージ間依存が循環しコンパイルエラーをおこします。

課題と方針

一部のコード生成ツールには外部参照先の定義を埋め込む機能があるため検討しましたが、5GCの定義は巨大で一つにまとめるのは難しいと判断しました。 そのため前処理として5GCの仕様ファイル群から循環参照を取り除いたファイルを作ることにしました。

参照関係だけみると仕様ファイルはこんな感じになっています。これを元にどのような変更を加えたいか確認します。

凡例

たとえば次のような参照関係を持つ仕様ファイルはファイルレベルで循環グラフになっています。

循環参照を起こしている定義の具体例
循環参照を起こしている定義の具体例

スキーマを消してファイルだけ表示してみます。

ファイル間循環参照の具体例
ファイル間循環参照の具体例

この循環参照をとりのぞくためにスキーマ定義を移動します。 今回は仕様ファイル間に順序を定めて強制するようにしました。 順序があれば循環は現れません。またアルゴリズムが単純で実装も簡単です。 そして仕様ファイルから決定的な結果が得られます。これは大事な特性です。 もしかしたら焼きなまし法を使えば変更を少なく出来るかもしません。ですが結果が決定的にならないためコード生成には不適切です。

導入した順序にしたがって仕様ファイルに含めるスキーマ定義を決定していきます。 処理中のファイルから後ろのファイルに定義されたスキーマへの参照がある場合は今のファイルへ移動します。 スキーマは内部でさらに別のスキーマへ参照を持っているので再帰的に実行します。

日本語で書くと長いのですがやることは単純です。疑似コードや図を見れば理解できると思います。 次のような擬似コードになります。

func main() {
    removeCircularRefs(graph)
}
func removeCircularRefs(graph ファイルのグラフ) {
    sort.Sort(graph.仕様ファイルたち)
    for _, current := range graph.仕様ファイルたち {
        for _, ref := current.使われている参照たち {
            if ref.To.所属先ファイル が current または ref.To.所属先ファイル.処理済み {
                continue
            }
            参照先オブジェクトの定義ファイルを更新(ref.To, current)
        }
        ファイル.処理済み = true
    }
}
func 参照先オブジェクトの定義ファイルを更新(スキーマ, current 仕様ファイル) {
    スキーマ.所属先ファイル = current
    for _, ref := range スキーマ.参照しているところ {
        ref.仕様ファイルないに書かれている文字列 = currentを反映したobjectPathの値
    }
    スキーマ内部にある参照を探していたらcallbackを呼ぶ(スキーマ, func(ref) {
        if ref.To.所属先ファイル が current または ref.To.所属先ファイル.処理済み {
            return
        }
        参照先オブジェクトの定義ファイルを更新(ref.To, current)
    })
}

1つのスキーマ移動に伴う再帰的な変化と参照の変更を図にしました。 右のファイルから処理が進んでいきます。灰色のファイルが処理済みを表しています。

スキーマ移動の例
スキーマ移動の例

あと細かいことですがスキーマを移動すると元の定義場所が追えなくなるため名前に元の仕様ファイルを示すプレフィックスを付けました。

ファイル順序

このヒューリスティックではファイル順序が結果を大きく左右します。 まず素朴にファイル名を使ってみました。この方針を名前ベースと呼ぶことにします。 じつはいろいろなところから使われている ComonData3GPP TS29.571 に含まれていて後ろ側にあります。 昇順ではうまく行かなそうですね。実際に複雑なグラフになりました。画像にし忘れたのですが降順で実行しても良い結果になりませんでした。 そこでリンクを考慮することにして下のようにファイルの順序関係を比較しました。これをリンク集計ベースとと呼ぶことにします。

ファイル間参照関係を矢印で表現した図
ファイルの比較材料

func (m ファイル毎のリンク数の集計) Compare(o ファイル毎のリンク数の集計) int {
        // 1. ファイルに向かってくるエッジが多いと前にくる(先に処理する)
        if m.外部からの参照数 != o.外部からの参照数 {
                return -(m.m.外部からの参照数 - o.m.外部からの参照数)
        }
        // 2. ファイルから出ていくエッジが少ないと前にくる(先に処理する)
        if m.FromNum != o.FromNum {
                return m.外部への参照数 - o.外部への参照数
        }
        // 3. ファイル内部での参照が多いと前にくる(先に処理する)
        if m.LocalNum != o.LocalNum {
                return -(m.内部参照数 - o.内部参照数)
        }
        return 0
}

前処理の結果

リンク集計ベースでは名前ベースよりスキーマ移動を抑えられました。 処理結果を移動したスキーマ数・更新された参照数で比較します。

順序 移動したスキーマ 更新された参照数
ファイル名 809 17822
エッジ考慮 245 950

どちらの項目も減っていますが、更新された参照数が特に大きく影響を受けています。 これは多く参照されているスキーマを優先して位置を確定できているためだと考えています。 画像で確認するとわかりやすいと思ったので実際に比較してみます。

ファイル名の辞書順

まず基準となったファイル名による順序です。ファイル名は3GPPの各仕様書のzipに含まれており TSxxyyy_zzzz.yaml という形式を満たしています。

ファイル名に基づいた順序をつかって循環参照を取り除いた結果
ファイル名に基づいた順序をつかって循環参照を取り除いた結果

循環参照はなくなっているはずですが参照が錯綜していて読めません。

参照関係を利用

参照を集計して処理順を決めた実装ではグラフが落ち着きました。

参照を集計して順序を導入した結果
参照を集計して順序を導入した結果

改善するには

全てのファイルをまとめてスキーマ移動をせず、対象ファイルを小さなグループにわけられれば改善に繋がると考えています。 事前処理として強連結成分分解を使うのが適切で図の上段に対して強連結成分分割をして下段のように分割してから実行します。

強連結成分の抜き出し例の画像
強連結成分の抜き出し

振り返りと後日談

まだ強連結成分分解は試していません。まずGoでのコード生成を優先したからです。ところがコード生成は循環参照を取り除いてもまだ失敗します。

いくつか試したコード生成ツールでは事前に確認できていなかった細かい問題が重なりコード生成や生成済みコードのビルドが失敗しています。 また仮に動いたとしても5GCに頻出するoneOf,anyOfの多用されたコードは使い勝手が悪く採用に悩みます。

そのため今の時点ではどのコード生成ツールも採用できないと判断し強連結成分分解の検討はとめています。 (この文を書いてる間にogen-go/ogenはどうかと提案を受けたので試してみます)

おおむねOpenAPIのエコシステムは芳しくありませんでした。 そして生みの親のWeb界隈ではAPI定義にgRPCGraphQLといった代替技術が採用される傾向があります。 そのためモバイルコア業界からOpenAPIに貢献していかないとエコシステム(少なくともオープンなツール)の大きな改善は望めなそうだと感じています。 エコシステムを絶やさないように貢献し動きやすいモバイル業界にしたいですね。

GoBGPにBGP Extensions for the Mobile User Plane (MUP) SAFIを実装した話

この記事は BBSakura Networksアドベントカレンダー 2022 の2日目の記事です。

1日目の記事は早坂さんの 勝手にレポート!BBSakura の社員はどんな環境で仕事をしているのか? でした。

こんにちは。BBSakura Networksのテックリードを担当している日下部( @higebu )です。

普段はモバイルコアを開発しているチームのリーダーをしたり、社内のエンジニアが働きやすくなるような取り組みをやっています。

本日は最近行った GoBGP に BGP Extensions for the Mobile User Plane (MUP) SAFI を実装した話をしようと思います。

ソフトバンク株式会社様のプレスリリース、MECやネットワークスライシングを低コストかつ容易に実現する「SRv6 MUP」の開発に成功 にエンドースメントを出させていただいて以来、SRv6 MUPについて何も表に出しておりませんでしたが、何かをやっていることがお分かりいただけると思います。

※本記事で参照しているインターネットドラフトは下記の通りです。時間が経つと内容が古くなる可能性がありますので、ご了承ください。 - draft-ietf-dmm-srv6-mobile-uplane-22 - draft-mhkk-dmm-srv6mup-architecture-04 - draft-mpmz-bess-mup-safi-01

また、正しくないことを書いていたらご指摘お願いします 🙇

GoBGP とは

GoBGP とはGo言語で実装されたBGPデーモンで、基本的なアーキテクチャは下記のようになっています。

また、BGPプロトコルを話す部分はライブラリとして公開されており、自身のアプリケーションにBGPプロトコルを扱う機能を足すことができます。

具体的な例として、CiliumでBGPプロトコルのネイティブサポートのためにGoBGPが採用されています

BGP Extensions for the Mobile User Plane (MUP) SAFI とは

IETFで標準化中の SRv6 Mobile User Plane(MUP)アーキテクチャ では、BGPによってMUP Segment情報やセッション情報を変換した経路情報を広報することができると書いてあります。

このときに使うBGPプロトコルの拡張が BGP Extensions for the Mobile User Plane (MUP) SAFI です。

BGP-MUP SAFIの番号は8月にIANAでアサインされていて、番号は 85 です。(Subsequent Address Family Identifiers (SAFI) Parameters

また、SRv6 MUP Extended Communityの番号も8月にIANAでアサイン済みで、 0x0c となっています。(BGP Transitive Extended Community Types

これらの番号がアサインされたのを見てGoBGPでの実装を始めました。

後はインターネットドラフトを見てくださいでは後半の話がよくわからないと思いますので、MUP SAFIの構造、4つのRoute TypeとMUP Extended Communityについて簡単に説明します。

BGP MUP SAFI

BGP-MUP SAFIはBGP-MUPのために新しく定義されたSAFI(Subsequent Address Family Identifiers)です。 また、新しくBGP-MUPのためのNLRI、BGP-MUP NLRIも定義されており、構造は下記の通りになっています。

      +-----------------------------------+
      |    Architecture Type (1 octet)    |
      +-----------------------------------+
      |       Route Type (2 octets)       |
      +-----------------------------------+
      |         Length (1 octet)          |
      +-----------------------------------+
      |  Route Type specific (variable)   |
      +-----------------------------------+

Architecture Type は今のところ 3gpp-5g のみで、 1 になります。Route Type は下記の4つのTypeがあり、 Route Type specific (variable) には Route Type 毎に違う値が入ります。

        + 1 - Interwork Segment Discovery route;
        + 2 - Direct Segment Discovery route;
        + 3 - Type 1 Session Transformed (ST) route;
        + 4 - Type 2 Session Transformed (ST) route;

BGP Interwork Segment Discovery route

Interwork Segment Discovery route(ISD) はInterwork Segment情報を広報するときに使います。Interwork SegmentというのはモバイルネットワークのUプレーンプロトコルとMUP Segmentの間の接続性を提供するMUP Segmentのことです。

構造は下記の通りです。

      +-----------------------------------+
      |           RD  (8 octets)          |
      +-----------------------------------+
      |       Prefix Length (1 octet)     |
      +-----------------------------------+
      |        Prefix (variable)          |
      +-----------------------------------+

3gpp-5g ではPrefixはgNodeBのN3インターフェースのPrefixになります。

ドラフトの 3.3.1. Generation of the Interwork Segment Discovery route を見ると、Route Target Extended Communityを付けるのが必須になっており、MP_REACH_NLRIのnexthopアドレスはIPv6でないといけません。

また、Prefix SID Attributeも必須で、AFIがAFI_IPの場合はFunctionを End.M.GTP4.E、 AFIがAFI_IP6の場合はFunctionを End.M.GTP6.E にすることになっています。

BGP Direct Segment Discovery route

Direct Segment Discovery route(DSD)はDirect Segment情報を広報するときに使います。Direct SegmentというのはMUP Segment同士の接続性を提供するMUP Segmentのことです。

構造は下記の通りです。

      +-----------------------------------+
      |           RD  (8 octets)          |
      +-----------------------------------+
      |        Address (4 or 16 octets)   |
      +-----------------------------------+

AddressにはPEのユニークなID(Router IDなど)が入ります。

ドラフトの 3.3.4. Generation of the Direct Segment Discovery route を見ると、Route Target Extended CommunityとMUP Extended Communityが必須になっており、ISD同様、MP_REACH_NLRIのnexthopアドレスはIPv6でないといけません。

MUP Extended CommunityにはDirect Segment Identifierを入れる必要があります。

また、こちらもPrefix SID Attributeが必須で、End.DT4/6、End.DX4/6、End.M.GTP4/6.E辺りが使われそうということになっています。

BGP Type 1 Session Transformed (ST) Route

Type 1 Session Transformed (ST) RouteはMUP-Cが広報する、モバイルネットワーク側のセッション情報を変換した経路情報のうちの1つで、Downlink方向で使う情報が入っており、PEではISDの情報と一緒に使います。

構造は下記の通りです。

      +-----------------------------------+
      |           RD  (8 octets)          |
      +-----------------------------------+
      |      Prefix Length (1 octet)      |
      +-----------------------------------+
      |         Prefix (variable)         |
      +-----------------------------------+
      | Architecture specific (variable)  |
      +-----------------------------------+

3gpp-5g ではPrefixはUEのアドレスになります。

また、3.1.3.1. 3gpp-5g Specific BGP Type 1 ST Route3gpp-5g のときの Architecture specific (variable) が書いてあり、構造は下記の通りです。

      +-----------------------------------+
      |          TEID (4 octets)          |
      +-----------------------------------+
      |          QFI (1 octet)            |
      +-----------------------------------+
      | Endpoint Address Length (1 octet) |
      +-----------------------------------+
      |    Endpoint Address (variable)    |
      +-----------------------------------+

これはGTPトンネルの情報になっており、Endpoint AddressはgNodeBのN3インターフェースのアドレスになります。SRv6 MUPではこの情報がSRv6パケットのSIDに含まれるArgs.Mob.Sessionに入り、最終的にgNodeB宛てのGTPのパケットのヘッダにエンコーディングされます。

3.3.7. Generation of the Type 1 ST Route を見ると、Route Target Extended Communityを付けるべき(SHOULD)となっており、正しいDirect Segmentにimportされるようにしましょうと書いてあります。

また、nexthopはMUP-Cのアドレスです。

BGP Type 2 Session Transformed (ST) Route

Type 2 Session Transformed (ST) RouteはMUP-Cが広報する、モバイルネットワーク側のセッション情報を変換した経路情報のうちの1つで、Uplink方向で使う情報が入っており、PEではDSDの情報と一緒に使います。

構造は下記の通りです。

      +-----------------------------------+
      |           RD  (8 octets)          |
      +-----------------------------------+
      |      Endpoint Length (1 octet)    |
      +-----------------------------------+
      |      Endpoint Address (variable)  |
      +-----------------------------------+
      | Architecture specific Endpoint    |
      |         Identifier (variable)     |
      +-----------------------------------+

Endpoint AddressはUPFのN3インターフェースのアドレスです。

また、3.1.4.1. 3gpp-5g Specific BGP Type 2 ST Route3gpp-5g のときの Architecture specific Endpoint Identifier (variable) が書いてあり、構造は下記の通りです。

      +-----------------------------------+
      |          TEID (0-4 octets)        |
      +-----------------------------------+

このTEIDはコアサイド(UPF側)のTEIDです。

3.3.10. Generation of the Type 2 ST Route を見ると、Route Target Extended Communityが必須になっていて、正しいInterwork Segmentにimportされるようにしなければならないことになっています。

また、MUP Extended Communityも必須で、この経路情報を使うDirect Segmentに対応したDirect Segment Identifierを付けなければなりません。 nexthopはType 1同様、MUP-Cのアドレスです。

GoBGP で BGP-MUP を使う方法

※ここからGoBGPのリポジトリへのリンクやコードの説明が出てきますが、 2022/12/02時点の最新のコミット をベースにしています。

使い方は GoBGP のリポジトリ内のドキュメント に記載しているのですが、ここでも簡単に説明します。

まず、下記のように ipv4-mup を有効にしたコンフィグを用意し、gobgpdを起動します。

[global.config]
    as = 65000
    router-id = "10.0.0.1"
    local-address-list = ["10.0.0.1"]

[[neighbors]]
    [neighbors.config]
        peer-as = 65000
        local-as = 65000
        neighbor-address = "10.0.0.2"
    [[neighbors.afi-safis]]
        [neighbors.afi-safis.config]
            afi-safi-name = "ipv4-mup"

こうすると ipv4-mup の address familiy が有効になるので、下記のようなコマンドでBGP-MUPの経路をRIBに追加できます。

gobgp global rib add -a ipv4-mup isd 10.0.0.0/24 rd 100:100 prefix 2001:db8:1:1::/64 locator-node-length 24 function-length 16 behavior ENDM_GTP4E rt 10:10 nexthop 2001::2
gobgp global rib add -a ipv4-mup dsd 10.0.0.1 rd 100:100 prefix 2001:db8:1:1::/64 locator-node-length 24 function-length 16 behavior END_DT4 rt 10:10 mup 10:10 nexthop 2001::2
gobgp global rib add -a ipv4-mup t1st 192.168.0.1/32 rd 100:100 rt 10:10 teid 12345 qfi 9 endpoint 10.0.0.1 nexthop 10.0.0.2
gobgp global rib add -a ipv4-mup t2st 10.0.0.1 rd 100:100 rt 10:10 teid 12345 mup 10:10 nexthop 10.0.0.2

ipv6-mup を使いたいときは ipv4-mup の部分を ipv6-mup に置き替えてください。

ドキュメントには 2つのnetnsの中でgobgpdを起動し、経路を広報する例 を載せています。パケットも見ることができるため、こちらを試してみるのがおすすめです。

パケットを見たい場合は開発版のWiresharkが必要です。 こちら からダウンロードしてください。

yuyarinさんのパッチ が入っているためBGP-MUPのパケットをきれいに見ることができます。

GoBGP に Extended Community と SAFI を追加するには

ここではGoBGPにBGP-MUPを実装したときに行った下記の点について、それぞれ説明します。 - BGPパケットのパース、生成 - RIBで経路を持ってもらう方法 - APIで経路を扱えるようにする方法 - CLIで経路を操作できるようにする方法 - シナリオテストの追加

BGPパケットのパース、生成

BGPパケットのパース、生成に関するコードは全て pkg/packet/bgp にあります。特に1万行以上ある pkg/packet/bgp/bgp.go に多くのコードが集中しているため、ここを読んでいくと大体わかると思いますが、読むのが大変なので、以下にポイントをまとめておきます。

今回は bgp.go に追記が必要な部分以外のBGP-MUP関連のコードをまとめた mup.go を新しく追加しました。

RIBで経路を持ってもらう方法

RIBは internal/pkg/table パッケージで管理されていて、この中の table.gopath.go を見るとNLRI毎の処理をしている部分が見つかります。

具体的には func (v Vrf) ToGlobalPath(path Path) errorfunc (p Path) ToGlobal(vrf Vrf) *Path func (t Table) deletePathsByVrf(vrf Vrf) []*Path です。

ここにcaseを足すことで新しいNLRIがRIBに入るようになります。

新しいNLRIをRIBに入れるには上記のみで良さそうに見えますが、実際はコンフィグの neighbors.afi-safis.config.afi-safi-name で新しいAFI/SAFIを指定できるようにしないとテーブルが初期化されず、APICLIで経路を投入しても何も起きません。

コンフィグで新しいAFI/SAFIを扱えるようにするには internal/pkg/config/bgp_configs.goAfiSafiType に新しいAFI/SAFIを追加します。

今回は ipv4-mupipv6-mup を追加しました。

APIで経路を扱えるようにする方法

protoファイルの編集

GoBGPはAPI定義に Protocol Buffers を使っており、 api ディレクトリにprotoファイルと生成されたGoのソースファイルが置いてあります。

APIを編集したい場合はここのprotoファイルを編集し、コードを生成することになります。

SAFIの番号は enum Safi に、NLRI や Extended Community は api/attribute.proto に定義されています。

コード生成は tools/grpc/genproto.sh でやっており、コマンドは下記のようになります。(これを実行するには事前に protocコマンドのインストール が必要です。)

./tools/grpc/genproto.sh

また、 api/attribute.protoenum SRv6Behavior を追加したときは go generate ./pkg/packet/bgp を実行し、 pkg/packet/bgp/srbehavior.gopkg/packet/bgp/srbehavior_string.go を生成し直しておく必要があります。

structの詰め替え

APIでやり取りするときに使う自動生成されたstructとbgpパッケージ側で使うstructは違うため、相互に詰め替えが必要になります。

この辺りの処理を行う関数は pkg/apiutil パッケージにまとまっており、 func MarshalNLRI(value bgp.AddrPrefixInterface) (*apb.Any, error)func UnmarshalNLRI(rf bgp.RouteFamily, an *apb.Any) (bgp.AddrPrefixInterface, error) がこれに当たります。Type SwitchでNLRI毎の処理をしているので、新しいNLRIのcaseを追加することで、APIでの経路情報の操作が可能になります。

Extended Communityも同様で、func NewExtendedCommunitiesAttributeFromNative(a bgp.PathAttributeExtendedCommunities) (api.ExtendedCommunitiesAttribute, error)func unmarshalExComm(a api.ExtendedCommunitiesAttribute) (bgp.PathAttributeExtendedCommunities, error) に新しいExtended Community用の処理を追加する必要があります。

CLIで経路を操作できるようにする方法

CLIのソースは cmd/gobgp 配下にあります。

今回追加した MUP Extended Communityをパースするための関数 や、 それぞれのRoute Typeの引数をパースするための関数 を読むと雰囲気がわかると思います。

これらの関数が func parsePath(rf bgp.RouteFamily, args string) (*api.Path, error) という関数から呼ばれることで、追加したコマンドがパースされるようになります。

また、ヘルプメッセージは func modPath(resource string, name, modtype string, args string) error という関数内に書くようになっています。

その他に、経路の表示については cmd/gobgp/neighbor.go にshow系の関数がまとまっていて、こちらも少しコードを追加しています。

cmd/gobgp/common.go にある func checkAddressFamily(def api.Family) (api.Family, error) に使いたい address familiy を書いておかないとCLIがエラーになるところには結構ハマりました。。。

シナリオテストの追加

GoBGPではDockerコンテナとしてgobgpdを起動することで、gobgpd同士や他のBGPデーモンとの経路広報のテストをGitHub Actionsで実行するようになっています。

シナリオは test/scenario_test ディレクトリ配下のPythonスクリプトになっており、テストフレームワークとしては nose が使われています。

今回追加したシナリオは mup_test.py です。

setUpClass に書いてある通り、 test/lib/gobgp.py にある GoBGPContainer クラスを使うと簡単にコンテナを作って、ピアの追加をすることができるようになっており、後はテストを書くだけとなっています。便利ですね。

テストの内容は test_02_add_del_mup_route にあり、経路をadd/delしつつ、addしたときに期待した経路が入っているかどうかチェックしています。

テストの実行方法は README に書いてありますが、コンテナをビルドした後にMUPの場合は下記のようなコマンドでテストできます。

PYTHONPATH=./test python3 test/scenario_test/mup_test.py --gobgp-image=gobgp

GoBGP に BGP Extensions for the Mobile User Plane (MUP) SAFI を実装すると何がうれしいのか

今のところ、世の中には他にOSSのBGP-MUP実装がないのですが、BGP-MUPに対応したGoBGPはMUP-CやMUP-PEを実装したいときのBGPの部分に使うことができます。

また、本来MUP-CのNorthbound API(未定義)から投入することになっているセッション情報を元にしたType 1 ST Route、Type 2 ST RouteをAPICLIから投入することができ、SRv6 MUPの検証が捗るようになります。

最後に

今回は、GoBGPに BGP Extensions for the Mobile User Plane (MUP) SAFI を実装した話について紹介させていただきました。

BBSakura NetworksではこのようにIETFで標準化中の新しい技術を使った業務を普段から行っており、BGPやSRv6等のネットワーク技術に明るく、3GPPの仕様が読めて、プログラミングもできる仲間を募集しています。

気になった方は 採用情報 からご連絡ください。

よろしくお願いいたします。

勝手にレポート!BBSakura の社員はどんな環境で仕事をしているのか?

この記事はBBSakura Networksアドベントカレンダー 2022の1日目の記事です。

前回のBBSakura Networksアドベントカレンダー 2019を見たい方はこちら

まえおき

こんにちは、BBSakura Networks モバイルコア開発チームの早坂です!

BBSakura Networksができて今年で三年目、三年前と比べると随分と我々もチームメンバーが増えましたがまだまだ我々の目指すいろんなものがつながり合う世界には程遠くその世界にたどり着くために日夜開発を頑張っています。

また、我々は基本的は会社全体としてフルリモートで働いていて北は北海道、南は大阪や京都という日本全国で弊社のメンバーが働いています。

そんな中、とあるところから聞こえてきたのが

「どんな働き方やどんな人がいるのか少し謎に包まれてる会社だよね」

「BBSakuraに転職する際に全然情報がなくて困った(´;ω;`)ブワッ」 と言う声が...そこでBBSakura社員にアンケート取材を行い、BBSakura社員の仕事の環境をネタにした本記事を執筆をしました。

今回の記事のテーマは

社員はどんなキーボードやマウスを使っているのか!!! みなさまは入出力機器にこだわりをお持ちですか!?

自分の使いやすいキーボードやマウス、目の疲れにくいディスプレイなどなど… 弊社は入出力機器の持ち込み利用は自由になっていますので人によっては大変こだわりも強く、BBSにはどんな人たちがいるかが透けて見えるのではないか!?と思いこのテーマにしました。

そんな弊社社員の机事情を北から南に向けて写真とともにお届けしたいと思います。お楽しみに!

北海道編

ここからは北海道在住の会社のメンバーの机をご紹介します!

その1

小樽在住の30代後半の男性、テックリードの作業場の風景です。プログラマーの机感を感じます!

以下に机のものをご紹介します!

  • PC: 見えてるのはさくらの標準PC
  • 机: オカムラ リーガス
  • 椅子: オカムラ シルフィー
  • ディスプレイ: 31.5インチ 4K
  • キーボード: Helix 4行版(Gateron Silent Red)
  • マウス: Kensington Expert Mouse
  • ヘッドホン: Sennheiser HD6XX
  • Webカメラ: Logicool C920
  • マイク: Blue Yeti

さくらインターネットから出向しているのでPCはさくらインターネットから貸与されたPCを使ってます。

iPadはBBSakura支給のもので、3GPPとか弊社で全員が読み放題になってるオライリーeBookを読むときに便利に使っているとのことです。

こだわりはマイクで

リモート会議では音質が大事だが、自分があまりハキハキしゃべらない人なので、マイクでカバーしようとしている とのことだそうです。

ディスプレイにかかってるのはお子さんからの父の日でもらったプレゼントのようです!かわいいですね〜💕

その2

続いては小樽在住の30代前半の女性、モバイルコア開発チームのエンジニアの作業場です。(よく見るとCiscoのスイッチが置いてたりしてて気になる作業場...!)

先ほどのその1で書いたテックリードとご夫婦で開発に取り組まれてます。

  • PC: BBSakura貸与のThinkPad T490
  • ディスプレイ: BenQの32インチ4K
  • キーボード: corne cherry
  • マウス: Kensington Expart Mouse Wired Trackball
  • デスク: FlexiSpot E7L(電動昇降L字デスク)脚 + マルトクショップでオーダーした杉の天板
  • 椅子: バウヒュッテ フルメッシュゲーミングチェア

写真にうつっている弧状のものはスタンドライトだったり、大変こだわりを感じますが特にファシリティにもこだわってるらしく、

LANケーブルはコンセントから壁に入って"ネットワーク機器とか置いてる棚"に、HDMIケーブルもおなじく壁内を通って壁掛けしているテレビにつながってます とのことでした。ここ以外にもネットワーク機器があるなんてエンジニアとしてはワクワクしちゃいますね!

ちなみにネットワーク機器周辺の写真はこちら

  • Cisco 2960G(とりあえず小型ONUを挿してる)
  • YAMAHA RTX1210(自宅のコアルータ)
  • Ubiquiti Switch Aggregation(自宅内で10G通したいときに使う)
  • Ubiquiti Switch8 (60W)(自宅内の天井に3つあるWi-Fi APにつながってるPoEスイッチ)
  • Ubiquiti Dream Machine Pro(Wi-Fi AP管理)
  • ミニPCにはCML2が入ってる
  • APはU6 ProとU6 Lite

Ubiquitiをメインにしたネットワークになってて素晴らしいですね✨!自分も欲しい....(いいなー

その3

石狩在住の40代前半の男性、モバイルコア開発チームのエンジニアの作業場です。二枚の4Kディスプレイなのがかっこいいですね!

  • PC:会社貸与のMacBook Pro (16-inch, 2019)
  • キーボード:Apple 純正キーボード
  • マウス:Apple 純正マウス
  • ディスプレイ:EIZO 27 インチ x 2 枚

この方はさくらのセキュアモバイルコネクトの運用もやられているので、「ラズパイ+ LTE モジュール」は通信テストで使用しているみたいです。

こだわりポイントはクラムシェルモードで利用して、それでいてキーボード類は純正のApple製品を使ってるので純粋なMacのデスクトップ環境を作ってるのがポイントみたいです!大変気合が入ってますね...!(なおカメラの消し忘れに怯えることになるのが辛いところらしい)

ちなみに人形は娘さんが置いたものらしく、朝放送してる某有名キャラクターが映ってて家族の中の良さを感じますね〜!

関東-東北編

ここからは東北から関東にかけてのメンバーの机(作業場)を紹介していきます。

その1

仙台在住の20代前半男性、OCX開発チームのエンジニアの作業場です。質実剛健な感じがいいですね!

  • 椅子、机: メーカー不明
  • PC: Dell Precision 7560(15inch, 2021)
  • ディスプレイ: acer KG251QHbmidpx 24.5インチ
  • キーボード:steelseries
  • マウス:logicool

彼のこだわりポイントはこの3つらしいです! - マウスは軽めのを選ぶ - 必ずなにかしらの甘いお菓子を置いてる - ESCキートップをさくら仕様にしていること

(これは)たしか入社式でもらった物のはず このさくらインターネットのロゴつきキートップさくらインターネットへの新卒入社特典のようです!

その2

栃木県在住の30代前半男性、OCX開発チームのエンジニアの作業場です。

主にOCXのクラウド接続まわりの仕組みを作ってるネットワークエンジニア、Go勉強中のこと。

  • 机:10年前に買ったIKEAの少し変わった机を、FlexiSpotの脚に取り替えて昇降デスク化して使用
  • 椅子:エルゴヒューマン、10年選手、肘掛けと首のやつは邪魔になって外しました
  • PC:会社貸与のMacBook Pro (14-inch, 2021 M1)
  • キーボード:Keychron K3ベースにキートップをカスタムして使用
  • マウス:ELECOMの安いやつ(壊れたら変えようと思って全然壊れない)
  • ディスプレイ:BenQ-E2200HD(2008年発売らしいので14年選手、全然壊れないから使い続けてる)

こだわりポイントはいろんなところにあるようですが、(キーボードもよくみると光ってる)特に机の空間をうまく使うための立体設計を含めた位置関係だそうです!

タテヨコ約1mの机を広々使うため、スタンド(写真左奥)を使って立体的に物を置けるようにしてる。上段にはiPadや領収書管理用クリアファイル、中段には文房具、下段にはノートを置いてる。ノートはmaruman N181A、めっちゃおすすめ。コップの位置も色々試して腕と腕の間に落ち着きました。 ディスプレイの付箋はもしやTODOリストなのかと思いきや、 ディスプレイ左下には忘れちゃいけない言葉を貼ってます、「良い仕事にしようと最初から思うな」などなど書いて貼って自分に言い聞かせてますw とても熱いエンジニアということが伝わってきますね!

その3

つくば在住の30代後半の男性、モバイルコア開発チームのエンジニアの作業場です。

  • 椅子、机: メーカー不明(ゲーミングな何か)
  • PC: MacBook Pro (13-inch, Intel Core i7, ...)
  • ディスプレイ: LG27インチを2枚
  • キーボード: Filco ピンク軸
  • マウス: Elecom EX-G

filco使いなのでこだわりがあるのかと思いきや、US配置の軽めのメカニカルなら何でも大丈夫とのこと。最近はマウスをトラックボールに変えたいとか。

ちなみに(机で写されてはないですが)

本棚に戻さないからどんどん机の右側が溢れていってます 会社だと綺麗にしろと言われて渋々片付けることになりますが、自宅だとうっかりテトリスのように山のようになりがちですよね😇

その4

東京在住の30代後半の男性、モバイルコア開発チームのエンジニアの作業場です。

最近はGoでの開発を勉強中のこと

  • PC: Intel MacbookPro13インチ
  • 机:カフェテーブル(作業環境ではないw)
  • 椅子:ない
  • ディスプレイ:ない....
  • キーボード:ない..............

お家でノマドワーカーをしているのがこだわりみたいです。カフェテーブルでお仕事してるのはとてもオシャレで素敵ですね〜いわくセキュリティには気をつけてるのこと。

壁紙をよく見ると描かれてる3GPPチックな絵柄がキラッと光りますね!

その5

東京在住の30代前半の男性、OCX開発チームのエンジニアの作業場です。

社内でDNSに詳しいエンジニアといえば彼なのですごく頼もしいです。

  • 椅子: アーロンチェア (リサイクルショップで購入)
  • 机: サンワダイレクト シンプルワークデスク
  • PC: MacBook Pro (14inch, 2021)
  • ディスプレイ: iiyama GB2760QSU-B1C 27インチ & DELL S2421HS 23.8インチ

机周辺にチラッと見えるキムワイプやマイク設備やSwitchがオタクとしての信頼性が高くて日々の生活がここで行われていることがわかっていいなーと思います!

その6

横浜在住の40代前半の男性、我らがCMOの作業場です。

  • PC: MacBook Pro (14inch, 2021)
  • ディスプレイ: 会社貸与の32インチ 4K

実はBBSakuraではリモート勤務の都合上会社からディスプレイやモニターアームを貸与しています。入社したらちゃんと会社のような環境を構築することが可能です!

よく見るとDATA-EX賞 データ社会推進 功労者賞のトロフィーがあってかっこいいですね!

その7

千葉在住の40代前半の男性、我らがCEOの作業場です。

  • 椅子: イトーキ C-サリダチェア (コストコで購入)
  • 机: Flexispot
  • PC: MacBook Pro (14inch, 2021) & 親会社(BBIX)貸与のLenovo PC
  • ディスプレイ: 会社貸与の32インチ 4K
  • キーボード: realforce

右にチラッと見える印刷機が自宅がオフィスって感じになってるのが伝わるいい写真だなーと思います。

ところで人間の腕は2本なんですが、キーボードが二枚あるのは一体どういうことなのでしょうね...

関西編

ここからは関西在住のメンバーの机(作業場)を紹介していきます。

その1

京都在住の20代後半の男性、OCX開発チームリーダーのエンジニアの作業場です。

  • 椅子: オカムラ シルフィー(オフィスバスターで購入)
  • 机: 無印良品 折りたたみ机
  • PC: M1 MacBook Air
  • ディスプレイ: 会社貸与の27インチ 4K

ここにもシルフィーユーザーが!マウスパッドのロックマンがかわいいですね〜!

その2

続いては自分です。こちらは京都在住の20代前半の男性、モバイルコア開発チームのエンジニアの作業場です。

最近はGoとかCを書いたりしてます!

  • PC: M1 MacbookPro16インチ
  • 椅子: ゲーミングアーロンチェア
  • ディスプレイ: dell 5k2kディスプレイ, dell 4k 27インチ
  • キーボード: Thinkpad usb keyboard
  • インプットデバイス trackpad & logi MX Master3

5k2kのディスプレイをコードを書くのに使い、そしてサブの4kディスプレイ縦おきを3GPPのTSを読むのに使っています ただサブはTwitter専用ディスプレイになることもしばしばです 😇

こだわりポイントは、Thinkpadのキーボードをわざわざ古いものを使ってる点です! Thinkpadのキーボードは実はT410と互換なのでそれを使えば換装可能でUS,JIS,UKなどに変更できます。なので大学からこれを愛用して生活してます!

その3

兵庫在住の40代後半の男性、モバイルコア開発チームのエンジニアの作業場です。

  • 机:奥行きあるやつ
  • 椅子:ニトリで買った普通の椅子
  • PC:会社から貸与してもらったMacBook Pro(14-inch, 2021)
  • ディスプレイ:会社から貸与してもらったBenq
  • 電卓:HP 50g

3GPPを読んでいたり、モバイルに関する本が積み上がっていてまさにモバイル開発のプロって感じですね!

ここでも会社貸与での4Kディスプレイを使ってる人がいるので買わずとも自宅設備を整えれるのは嬉しいですね〜

その4

こちらは兵庫在住の30代前半の男性、BBIXのシステム開発エンジニアの作業場です。 最近はNext.jsとかGoでアプリを作る人をやっているとのこと。

  • 机:特にこだわっていない広いやつ。昇降のやつがほしい
  • 椅子:エルゴヒューマン
  • PC:BBSakura貸与品のMacBook Pro (16-inch, 2019),core i9のやつ,(奥のMac miniは私物)
  • キーボード:メインは分離キーボードのMoonlander,奥に控えてるのはサブのリアルフォース。他にも出張用にHHKBあり
  • マウス:LogiのMX Ergo
  • ディスプレイ:BBSakura貸与品の27インチが2枚

大変入力デバイス周辺にこだわりを感じますね!

本人曰くもこだわりは分離キーボードと万年筆とのこと。ちなみに万年筆のインクは青墨が推しらしいです!

番外編

弊社社員には実は海外の拠点で活躍されてる方もいらっしゃいます。今回はそちらの一枚もお願いして記事にしました。

シンガポール

シンガポール在住の40代前半の男性、BBIX Singaporeの成長にかかる諸々を取り組んでいるエンジニアです!

  • PC:Thinkpad X1
  • 椅子:WeWork 標準
  • ディスプレイ:ASUS PB278
  • マウス:Microsoft Mobile Mouse 3600

Weworkがシンガポールにもあるのでそこで普段は働いているみたいです。BBIX Singapore に関しての発展が楽しみですね!

最後に

仕事場レポートいかがでしたでしょうか!みんなに机の写真をくれ!頼む!とSlackでお願いしまくったところ、

机周辺を片付けないといけないのがつらい😭

出すのが恥ずかしい...🥺

みたいな反応が来てなかなか集まらなくて大変でした...🥺🥺🥺 写真にご協力してくださった会社の人たちにはこの場を借りて御礼申し上げます。

個人的な感想はキーボード結構みんなこだわってるなーというのが衝撃的でした。割とみんな分離キーボードじゃん・・・というのがびっくりです(なお、自分は分離キーボード慣れなくて自作したけど結局Thinkpadキーボードに戻ってしまいました・・・😇)

記事を振り返るとかなり個性豊かでこだわりを感じられる机(仕事場)だったのではないかなーと思います。本当はもっと近くで見させて貰えばキーボードのすり減りから打鍵の癖とか面白いものがわかったのかも...とは思いましたので、他の社員が増えた時や趣味趣向をもっと集めてみて記事にしても面白いなーと思いました。

とはいえ自宅だからこそノビノビとした環境でやれていることが伝わる記事なのではないかと思います。BBSってどんなところなのかなと気になる人への一助になればと嬉しいです。

以上、お付き合い頂きありがとうございました!

エッ、また進化したの!

改めまして、こんにちは。BBSakura Networksの夏(@xia)です。
この記事はBBSakura Networkのアドベントカレンダー 23日目です! 多分中国テクノロジーに関する様々な記事があると思いますが、ここでは自分の経験とそれの感想について書きたいと思います。

私は高校卒業後、来日し今でも年1回や2回中国に帰ります。こんな頻度で帰国しても、その度に、「エッ、また進化したの!」と思ってしまいます。

先月、中国のお店で会計する際に、店員さんに当たり前な感じで「支払い方法はアリペイ、それともwechat payですか?」と聞かれました。現金しか持ってない私は「あっ、、現金です」と回答したら、まるで田舎から来た娘と見られてしまいました。
スーパーで買い物した最後、店員さんに会計してもらおうと思ったのに、弟は「先ほど箱に入れたものを全部自分でスマホでスキャンしてたので、既にスマホで自動会計済で、あとは店員さんがそのリストと買った商品を確認するだけでいいよ」と言ったら、「エッ、また進化した」としか言えないです。

出前デリバリーサービス(外卖)は出前デリバリーサービスだけではない

中国の街ではユニフォームを着てる出前の配達員をよく見ます。 出前デリバリーサービスが普及されてる為、ランチタイムには、ほとんどの方は出前を注文し、ほぼ30分以内指定場所に届けられます。iiMedia Researchのデータにより、2018年の中国の出前注文するユーザーの規模は2017年と比較して17.4%増加し、3億5800万人に達し、2019年には4億人を超え、その成長率はまたまた続くと言われています。
そのアプリ機能は主に
 ・注文・評価機能
 ・オンライン会計機能
 ・配達員居場所がリアルタイムで確認機能(GIS)
ぐらいだと思う方が多いかもしれませんが、実際にはそれだけではありません。 これはとある出前注文アプリの操作画面です。出前注文アプリなのに、ホテル予約、タクシー呼ぶ、映画館チケット予約、医療方面、様々なサービスも含めています。また、デリバリー内容は出前だけではなくて、欲しいもをデリバリーのお兄さんに頼めば、ほとんど届けてくれます。近年、夜間に胃薬や風邪薬など非処方せん薬を買えるようなサービスも出てきました。
中国では、デリバリーお兄さんが「世の中で届けられないものはほとんどない」とよくに言われています。
本当に便利です、もし中国へ行く機会があれば、ぜひそのサービスを体験してみてください。

Wechatはchatだけではない

Wechatは中国版Lineです。中国では日常生活に欠かせないアプリだと思います。
この前、中国ホテルを予約しましたが、色々リクエストがあるため、相手のwechatを追加しました。店員さんがほぼ24時間対応してくれて、現地の写真や天気情報は全てwechat経由で提供してくれました。中国ではビジネスの場合でも、wechatでコミュニケーションするのは主流です。日本で電話かメールしか問い合わせできないことと比較して、それに本当に感動しました。
もちろん、チャット機能以外、水道光熱費用、会社保険支払い、携帯・インターネットなど費用チャージなど、様さまなオンライン会計サービスを提供しています。
三者提供されるサービス、タクシー呼ぶアプリ、デリバリーアプリ、オンラインショッピングアプリもwechatと連携して利用できます。saasを提供されている為、技術者が簡単にアプリを開発するのもできます。
一方人口が多い中国では、病院の予約は社会問題です。wechatはそれに対して、2016年からオンライン病院予約サービスを提供始めます。携帯の位置によって、そのシティーの病院や地域保健サービスセンターの情報を提供し、オンライン予約、電子診療情報作成、オンライン問診など、様々なサービスを提供します。
自分もその機能を試してやってみました。

独身の日(11/11)もう寂しくない

元々中国の11月11日は「光棍節(こうこんせつ)」と呼ばれており、日付の1人を連想させる「1」が並ぶことから一般的に独身の日という意味合いが広まりました。 2009年、そこに目をつけたアリババは、同年11月11日に中国でECサイトの大規模な販促イベントを開催。
今年はちょうど独身の日セール開催の10年目です。わずか1分間で1000億円、一日5兆円売上達成しました。また記録を更新しました。
なぜこんな大量のデータのやり取りができるでしょうか?サーバーの冷却処理は大丈夫でしょうか?
アリババ自社開発の液浸冷却や浸水空冷をはじめとするグリーンテクノロジーにより、Eコマース取引1万件あたりの電力消費量を2kWhまで低減しました。これにより「天猫ダブルイレブン」のデータセンター全体の消費電力量を昨年から70%削減して20万kWh以上の省電力を実現したそうです。

なぜいつも進化していますか

では、なぜ常に進化していますか? 政府の協力と技術の発展はもちろんですが、私は失敗を恐れず、チャンスとスピードが優先は最も大きな理由だと思います。
中国IT産業は世界の最先端で走ってるとよく言われていますが、この20年の発展を振り返ってみると、順調とわ言えないです。例えば、シェア自転車事業の初期段階で、大量遺失や路上放棄と言った社会問題、ネット通販でも消費者損壊事項が数多く発生したなど、様々で問題が発生してしまいました。
「昨日より今日はよくなる」、これは中国でよく言われてる言葉です。あらゆる規制や障害に挑戦しながら、試行錯誤を繰り返して、その結果は現在どんどん便利になってる生活だろう。
その繰り返しの結果で、50代のお母さんはDiDiでタクシーを呼ぶのは常識だと思い、街の豆腐屋さんでもQRコードで決済するのは当たり前なことで、飲食店でマシンでセルフ注文、セルフ会計は普通なことで、携帯さえあれば、なんでもできちゃう生活になってきます。

年末にはまた中国に帰りますが、次の進化、楽しみしています^^

Challenges of working remotely in a Japanese IT Company

Hello. This blog article is part of the advent calendar series of blog posts for the year 2019. Click here for the links to the other blog posts.

I am not a big fan of long blog posts and neither am I good at writing long articles so I will try to keep this as short as possible. To be honest, this may probably be my first blog post in English.

Introductions first

My name is Atreya and I work as a software engineer at BBSakura Networks. I am striving to become one of those full-stack engineers (although I am still a long way off from becoming one).

The keyword here is "Remote"

All members of our engineering team work remotely, some work from home (like me), and some work at the office and we are spread out in different locations within Japan.

Being a completely remote team most of our interactions are done textually via Slack. We do have weekly teleconferences etc. but most of the day to day conversations happen almost completely within Slack.

Work Culture

To be honest, I have been using slack for only about a year. Initially, I was excited because I don't have that many emails to check on anymore.

However, it slowly dawned upon me that I couldn't get used to textual communication, especially in a foreign language. I had to read and write Japanese almost all day long to communicate with my colleagues and it was starting to become a big cognitive burden (especially because I have read Kanji all day long, my eyes hurt!)

Switching to English did not help that much because my colleagues took a longer time to respond because they had to first understand what I was talking about.

Communicating using the Japanese language is not the same as using the English language and I do not want to get into the specifics of how they are different. But it suffices to say that the English language, for example, promotes direct speech more than indirect speech which is more frequently used in Japanese. And this only complicates things.

Issues that could probably get resolved within minutes, if I just went to my colleagues' desk and had a small chat, took at least an hour to just get my point across. I am not trying to be negative here or implying that the work culture is bad. On the contrary, since everyone works remotely, all my colleagues are kind enough to answer any stupid questions that I have and I am grateful for that.

I have this habit of asking “why” all the time because I want to know the reason behind certain questions and actions. This becomes very important especially in the context of textual communication as all you have in front of you are the words and not the facial expressions or emotions to back those words. So I make it a point to add emojis to most of the messages I send to add a bit of human touch to them.

And I think it’s important to maintain this work culture where any question, regardless of whether the said question is stupid or not, can be asked freely without being berated for it or being said that the answer to such a question is fundamental knowledge and/or common sense.

The reason may be obvious to the person asking the question but of course, the person asking the question cannot assume that the person who is going to answer the question understands the meaning and purpose of the question.

My closing thoughts

Since most of what I wrote may have sounded a bit negative, I would like to end this post on a positive note.

As human beings, (regardless of whether we are Japanese, American, etc.) we all have different ways of thinking and we should to listen to others and try to understand their way of thinking. The result may be good or bad, right or wrong but we cannot know that unless we discuss it. This is not restricted to just textual communication but all forms of communication. We are not robots after all.

And most importantly, whenever we are conversing online purely through text, we should always be mindful that there is a person who is typing those words and we should be considerate and give careful thought before we send a message to someone.

That's all folks!

DNS暗号化まわりについて雑に調査してみた件(前編)

こんにちは

冒頭から不穏な画像ですみません。

この記事はちょっと文字が多くて長いので、結論だけ気になる人は最後の方に貼ってある調査結果のグラフあたりから読んでください!

BBSakura Networksの牧です。この記事は BBSakura Networksのアドベントカレンダー 20日目です。

私たちがいつもお世話になっているDNSですが、いまだにそのほとんどの通信が暗号化されていないため、冒頭の画像のようにどのサーバにアクセスしようとしたのかが誰からでもわかる危険性があります。
そのような現状から、近年DNS通信の暗号化手法がいくつか出現しはじめています。

しかし、暗号化と聞くとまず「ちりつもで通信が遅くなるのでは?」とか思いますし、DNSなんて一般ユーザからしたらどうでもいいものを、わざわざ暗号化なんて「めんどくさそう」とか思います。
なので、この調査では - ① DNSに暗号化をかけるとやはり遅くなるのか? - ② 技術者でなくても簡単にDNSを暗号化できる方法はないか?

について雑に探ってみます!

今日の前編では、「① DNSに暗号化をかけるとやはり遅くなるのか?」について、DNS暗号化で名前解決のレイテンシを測定してみた結果をまとめます。

おことわり事項

  • 冒頭の画像は、実験目的で自分で生成したパケットをスニフィングしたものです。
  • この記事内では特定のサーバに対して大量にパケットを投げつけるような行為がありますが、健全な調査を目的とするものであり、すべてがnonadversarial(敵対を目的としない)のものです。

0. DNSの基本の仕組みを数行で

DNSコンテンツサーバはそのネットワーク内のDNSのボスで、ゾーン情報(そのネットワークにどんなドメインがあるのか)を管理しているサーバです。

一般的に、ユーザ端末(スマホなど)は DNSキャッシュサーバに対してDNSクエリを投げてサーバが持っているキャッシュからそのままDNS応答を得ます。
ですが、キャッシュなのでいつかはサーバから消えます(キャッシュのTTLはキャッシュサーバで任意に設定できる)。

その時にキャッシュサーバは、必要に応じて最新のレコードをコンテンツサーバに取りに行きます。

  • DNSキャッシュサーバ...ここではフルリゾルバ(リカーシブリゾルバ)の意味で使います。
  • DNSコンテンツサーバ...権威サーバとも言います。

1. (前座) DNS暗号化手法にはどんなものがある?

1.1. 冒頭ではしょった説明について

DNSの暗号化には、プライバシ保護を目的としないものと、プライバシ保護を目的とするものがあります。

「プライバシ保護を目的としないもの」は今から20年くらい前の1997年に RFC になっています。これは DNSSEC (RFC2065) です。

一方で、「プライバシ保護を目的とするもの」の方は最近いくつか手法が出てきており、 - DNS over TLS - DNS over DTLS - DNS over HTTPS - DNS over QUIC

などがあります。

冒頭では説明をはしょりましたが、この記事はこちらの「プライバシ保護を目的とするDNS暗号化」についてのものです。とくに DNS over TLS (DoT) について実験調査してみました。

1.2. 暗号化「DNSSEC」の用途

DNSSECは、コンテンツサーバへのDNSクエリに対する応答が 本当にちゃんとしたコンテンツサーバからの応答なのか?というのの検証のために存在します。
なりすましの返答じゃないよな?ということです。

また、暗号化するのはDNSのクエリ/応答の内容ではありません。差出人検証のために使う電子署名に暗号化を使っているよ〜ということなのです。つまり、プライバシの保護を目的としていません。

1.3. 暗号化「DNS over TLS」などの用途

一方で、こちらはプライバシの保護を目的としています。
どんなDNSレコードを問い合わせたのかはわからなくなります。つまり、DNSのクエリ/応答の内容をTLSなどで暗号化しているので、DNS通信の当事者以外は中身を見ることができません。

DNSSECとDNS over TLSはそれぞれ目的が違いますし、互いに独立した別々のメソッドです。なので、どちらが優れているとか劣っているということはなく、目的に合わせてそれぞれを選んだり組み合わせるというのが正しい使い方です。

2. (本題) レイテンシ測定&比較

2.1. 実験内容&条件

大雑把な測定です。 - 以下のパブリックな複数のリゾルバに対して、特定のドメイン・IP空間の名前解決を 正引き(ドメインからIPを得る)と逆引き(IPからドメインを得る)の両方で要求して比較しました。 - それぞれ DNS over TLS (DoT) と 従来の暗号化されていない平文(UDP) の両方で問い合わせました。Knot DNSプロジェクト による kdig というdigの拡張版みたいなツールを使いました。 - kdigでのTLS暗号化問い合わせは、毎回TLSハンドシェイクと切断が発生します。今回はこのハンドシェイクも含めたレイテンシ測定をしています。(厳密にいうとexecが走り始めてから応答を受け取るまでの時間を測定端末で測定しているので、測定端末内のオーバヘッドも含まれます) - 今回Wiresharkは見てません😫(pcapファイルが膨大になるので、、) - ハンドシェイクを除いた単純なクエリ時間についてはたぶん平文と一緒だと思って測定しませんでした(実装見たわけじゃないのにそう思う人) - 測定は日本国内のISPに接続された端末から実施しました。 - 確実にキャッシュを持っているときを測定したかったので、一回クエリを投げた後にキャッシュTTL以内に別プロセスで再度問い合わせをかけてそのレイテンシを計測しました

プロバイダ 対応タイプ IPアドレス フィルタリングの有無
Cloudflare DoT, DoH, UDP 1.1.1.1 なし
Google DoT, DoH, UDP 8.8.8.8 malicious domain
Quad9 DoT, DoH, UDP 9.9.9.9 malicious domain

malicious domain ... 既知の悪意あるドメインに関する問い合わせには応答しないという意味

2.2. レイテンシ測定結果と感想

2.2.1. レイテンシの表

正引き . . : 逆引き . .
ゾル 応答タイプ レイテンシ中央値 : ゾル 応答タイプ レイテンシ中央値
Cloudflare DoT 8.0 ms : Cloudflare DoT 91.5 ms
UDP 36.5 ms : UDP 92.1 ms
Google DoT 87.8 ms : Google DoT 113.7 ms
UDP 79.6 ms : UDP 117.6 ms
Quad9 DoT 251.7 ms : Quad9 DoT 118.7 ms
UDP 222.1 ms : UDP 114.6 ms

2.2.2. レイテンシのヒストグラム

青色...DoT、オレンジ色...UDP
横軸...レイテンシ(ms)、縦軸...そのレイテンシで来た応答の数

  • 正引き(Cloudflare, Google, Quad9)

  • 逆引き(Cloudflare, Google, Quad9)

2.2.3. 感想

まず上の結果をみて あれっ?となりました。平文のUDPの方が暗号化のDoTより応答が遅いようにも見えます。。。
(2000クエリくらい連続で同じサーバに投げると10分くらいブロックされてタイムアウト時間内に応答が返ってこなくなったので、何回かやり直した😭🙏)

とはいえ、ロードバランシングされてると思うので、実際に名前解決してくれたサーバが地理的にどのくらい離れているのかとか、その辺にもよるのでなんともいえません。

また、測定した時間帯がバラバラだったりしたので、時間帯による影響もややあるかもしれません。(もしクエリかけたリゾルバがヨーロッパにあったとしたら、ヨーロッパが昼の時間帯にヨーロッパ人のアクセスが多いかもしれない)
(本当になんともいえない)

もしかしたらDoT用のサーバが別経路にあって、そちらがすいていたので応答が早かった、、などあるでしょうか。
正引き逆引きそれぞれだいたい8~14時間くらいかかりました。(クエリのクールダウンタイム含む)

※ DoTは2016年にRFCになったばかりで、DoTの提供はCloudflareが去年2018年に、Googleが今年2019年に開始したばかりです。

3. 各種DNS暗号化手法の違いと特徴

3.1. DNS over TLS

DNS over TLS はRFC7858で標準化されており、RFC2246で標準化されている TLS(Transport Layer Security) を使ったDNS通信の暗号化手法です。TLSは、公開鍵と電子署名を使った暗号化プロトコルです。デフォルトのポートは853番です。

3.2. DNS over DTLS

DNS over DTLS はRFC8094で標準化されており、RFC4347で標準化されている DTLS(Datagram Transport Layer Security) を使ったDNS通信の暗号化手法です。DTLSはTLSみたいなことをデータグラムでも実現できるプロトコルです(TLSがストリーム単位の暗号化であるのに対し、DTLSはデータグラム単位の暗号化)。デフォルトのポートは853番です。

3.3. DNS over HTTPS

DNS over HTTPS はRFC8484で標準化されており、ブラウザやOSを新たに設定する必要のないDNS通信の暗号化手法です(すばらしい!)。GoogleDNS over HTTPS のWebAPIを試験的に公開しています。さらにDNS通信をHTTPSでラッピングするため、外部からはそもそも他のHTTPS通信と区別することができません(DNS通信が流れていることすらわかりません)。デフォルトのポートは通常のHTTPSと同じ443番です。

以下のようにブラウザにURLを打ち込むと、答えがJSONで返ってきます。

https://dns.google.com/resolve?name=www.bbsakura.net&type=A

詳しくは こちら をチェック!

3.4. DNS over QUIC

DNS over QUIC はGoogleが試験的に開発している QUIC(Quick UDP Internet Connections) を使ったDNS通信の暗号化手法です。QUICはトランスポート層プロトコルです。QUIC はIETFのドラフトになっていますが、2019年時点でまだRFCにはなっていません.

3.5. DNSCrypt

DNSCrypt は上記の他のメソッドと同じくクエリのスニフィングやスプーフィングを防止することを目的としていて、DNSCrypt Projectで推進されています。しかし、DNS over TLS とは異なりパケットのパディングがないためパケット長は可変です。他のメソッドと同じようにクエリの完全性は保証しますが、プライバシの保護の観点はありません(パケット長から中身を推測する攻撃手法もある)。こちらも2019年時点でまだ標準化されていません。

まとめ

  • DoTとUDPでレイテンシを比較してみたが、ハンドシェイク含めてもそんなに変わらないかもしれない
  • 調査対象のリゾルバは、どれも2000クエリくらい連続で投げるとその後10分くらいブロックされるconfig入ってる
  • セキュリティ的に一番いいのは、DNSサーバ間を DNSSEC と DoX で暗号化してくれることです
  • 単純に平文DNSのパフォーマンス比較は こちら などにアクセスすれば見ることができます

ふろく

DNS暗号化普及率はどれくらい低い?

WEBでよく使われているHTTPSの普及率は、Googleのブログ によれば、Android, Windows, Macで70%前後(2017年)です。

DNSは 1987年にRFC1035で標準化されましたが、そこから今に到るまで暗号化通信の普及率は低いままです。
APNICのこの地図 を見ると、いにしえのDNSSEC(1997年にRFC2065で標準化)でさえ この記事を書いた時点(2019年末)の世界で普及率わずか 24% です(リンク先では常に値が変動してます)

BBSakura Networksでの働き方

はじめに

この記事はBBSakura Networksアドベントカレンダー2019の16日目の記事です。

ブログの内容

おはようございます。

2019年8月1日で設立された、BBSakura Networksで取締役COOをやらせていただいている山口です。

すでに一日目のアドベントカレンダーでチームメンバーの方がリモートワーク前提の会社でのコミュニケーションの現状について記載させて頂いていますが、今日はそんなリモートワーク前提の会社の BBSakura Networks で新しいチームメンバーを迎えるにあたって、どういう方なら一緒にやっていけるか社内に聞いてみたことについても共有したいと思います。

リモートワークを取り入れておられる会社、これからリモートワークの制度を取り入れようとしておられる会社の方、責任者的な役割を持っておられる方たちに、ちょっとでも参考になればと思います〜

BBSakura Networksは比較的多様性のある会社だと思う

多様性というと色々ありますよね。多様性というのは、ただただたくさん種類があるというわけではなくて、一定の傾向を持っているまとまりが、その状態を維持しつつ活動を続けている状態です。

もともとは生物学や環境学てきな用語の生物多様性から来ているのかなと思いますが、環境省さんによると「生きものたちの豊かな個性とつながりのこと。」なので、ビジネス的の感じだと、個性的でありつつ連携をして目的を達成するために各自で変化と努力をし続ける状態ですかね。

ところで、BBSakura Networksですが、社員は東京に2拠点、大阪、北海道、(あとは各自の自宅)など拠点はあるけれども、同時にリモートワークもOKになっているので、拠点には必ずしもこだわらない働き方をしていると思っています。

さくらインターネットソフトバンクグループのBBIXのジョイント・ベンチャーということもあり、社員も両方から来ています。ですので、元々やっていた仕事も、固定キャリア、ISPクラウド事業者、IOT、MNOなど様々なところから集まってきています。

国籍は現在は日本、中国、インドですがこれからたくさん増えていきそうです。

こういった状態だと当然メンバー間の価値観も違いますし、同じ事柄についてどう考えるかについても全く違います。

しかし価値観を揃える必要性は全くないと考えていて、むしろ違いを生かしてそれぞれができることを最大限にやっていただけるように心理的安全性に配慮しつつ努力したいですね。

※ 心理的安全性で調べていたらめちゃくちゃしっかり書かれているQiitaを見つけたので興味のある方はどうぞ!

設立からまだ4ヶ月目ですが、そろそろ「アレアレ??なんか今まで普通だと思っていたこと何だけれども、お互いに話があわないぞ??」みたいな事も出てきていて、とても良いと思っています。

ぜひとも、「どっちかに寄せる〜」とか「それぞれの範囲で」ではなくて話をして理解し合っていきたです。

働き方

リモートワーク前提だと、どうしてもツールが多くなってしまうので、フロー情報については、Slackに連携をするなどして基本的には直接そのツールに触らなくても良いようにしたいと思っています。

出勤・退勤したタイミングもわからない(これはチームメンバーを守る立場の管理職としては良くない)ので、以前はタイムカードに出勤退勤を書いてもらっていたのですが、これがちょっとした手間でメンドイので、Slackに専用のコマンドを作ってSlackに書き込みをすれば、タイムカードに自動的に入力され、チャンネルにも出勤が記載されるので楽になったと実感できた良いものかなと思います。ちょっとした手間だからこそ無くせるもんなら無くしていきましょう。

 基本的には顔を突き合わせるメンバーがあまりいない、いても特定の少数の方のみという環境なので、拠点メンバーの方が対面で良いコミュニケーションが取れているかというと実際にはそうでもないです。

 他の人と音声や顔が見えるコミュニケーションを取るためには、基本的にG suite のmeetやSlack コール などを使っています。

このあたりの使い分けは、時間をきめて会議をする時にはmeet、ふとなにか気になって話がしたくなった時にはSlackコールみたいな感じなのかな?

さてさて新しいメンバーを募集したいんだけれども。。。

 リモートワークできる!やりたい!と言って新しいメンバーに参加いただいたとしても、実際にはじめてみると、どういうタイミングだったかやその時のチームの構成等などによって、チームから支えるべきところが異なっていそうという気がします。

状態や状況は常に変化し続けているので、その都度ごとにしっかりやっていかないといけないですね。

リモートワーク適正・適性

チームメンバーの採用をするにあたって、どんな素養が必要なのかチームメンバーに聞いてみました。

言語的なスキルやぼくらがやろうとしていることの大前提としてネットワークについてのなどが上がってきたのですが、チーム自体がリモートワーク前提なので「リモートワークが問題ないこと」、適正・適性があることということが複数のメンバーから挙げられました。

リモートワーク適正・適性

「適正」とは、「適当で正しいこと」。例文として「適正な手段」「評価が適正を欠く」

「適性」とは、「ある事に適している性質や能力。また、そのような素質・性格」

具体的な項目を聞いてみると

  • 人の声/表情が見えなくても不安にならない
  • 不安になったとしてもちゃんと伝えたいことを伝える
  • 気になったことは聞ける
  • 複数の意味が含まれる場合は聞き返せる
  • 文字だけではなく、他のコミュニケーション手段をもっている

とのことでした、リモートワークは比較的新しい働き方かなとも思います。

上記のことはインターネットを利用する際のリテラシに少し付け加えたものに近いですね。

表情が見えなくても不安にならない人もいます。表情が見えないと不安になるタイプの人もいます。不安になるタイプの方は、そうでない人に比べて、普段からストレスが発生してしまっているかもしれないので、適性はどちらかというと無いということになるかもしれませんが、自分がそういうタイプであれば、不安になったことを伝えることが大切ですし、チームメンバーが不安を伝えられるような雰囲気を常に意識するということも必要ですね。

リモートワーク文化醸成にむけて

Slackなどのコミュニケーションツールを使うと、今までのやり取りとは異なって、非同期でやり取りをするようになり、あとから辿れるようになるため、対面のフロー情報のコミュニケーションだけでは表面化してこなかったコミュニケーションの課題に向き合う必要が出てきます。これらの課題に向き合いリモートワークを円滑にするためには、必要になるシステムを使いこなせる能力、使いこなすための努力を続ける力ももちろん、広い意味でリモートワークの文化を醸成し理解しあうということも必要かもしれません。

会社側からの必要なフォローはもちろんですが、下記のようなことを相互に自発的にできるようになるとより快適にしていけるのではないでしょうか?

対面コミュニケーションが取れなくても過度なストレスにしないようにする

→ ネガティブな思考に向かいそうになったら対応できる

自律して仕事をする

→ こまかく指示受けなくても大丈夫!

慮ることができる (悪い意味での忖度は不要だよ!)

→ リモートの人もいれば、集まって仕事をしている人もいるよ

リモートワークの良いところに目を向ける

→ 課題もたくさんありますが、良いところをみましょう!

だいぶリモートワークの話になってしまいました。僕自身は会社を引っ張っていく立場になって、最近思うのは会社やチームは、まるでいきもののようだなということです。

いきものには心臓の役割をもっている細胞チームも、肝臓のように必要な物質を生産する細胞チームなどもたくさんありますよね。それらに何らかの外的刺激があった時に普段どおりの自分のチームだけが健康で万全な仕事をしていたとしても、体全体でみるとよりよくない状態になってしまうというのはよくあることです。(詳しくははたらく細胞15話でも見てくださいw)

会社組織もそれを構成していると自分自身どちらもヘルシーな状態にたもつ為にはどうしていけばよいか、できたばかりのBBSakura Networks ではまだまだいろいろな課題があります。そういった課題をチーム全体が自分ごととして解決していき続けられるような環境にしていきたいですね。

とりとめのない話になってしまいましたが。

こんな感じで楽しくやっていて、チームメンバーを募集しております!ご興味のある方はぜひお話し聞いてください〜