---
# System prepended metadata

title: 2022/12/14 minipro mid meeting @B208 and online
tags: [lab meeting]

---

###### tags: `lab meeting`
# 2022/12/14 minipro mid meeting @B208 and online

### 教員
- 藤川先生
- 新井先生
- 垣内先生
- 遠藤先生

### D3
- Kibrom
- 大平

### D1
- 桂

### M2
- 松永
- 福田
- 丹羽
- 山村

### M1
- 眞田
- 人見
## how to
- 議事録は質疑応答のみでOK．
- 発言者の頭文字を先頭につける．
    - f, 藤川先生
    - a, 新井先生
    - k, 垣内先生
    - e, 遠藤先生
    - oh, 大平さん
    - ... 学生は適当に名字2-3文字で
- f, 例：質問質問
    - 発表者の回答は1段下げて記載
    - 回答回答



## 人見
- ni, 実行結果のグラフとかあればわかりやすい
- ni, 動作の結果とかありますか？
    - http3の実測の結果があったけど
    - 結果がロストしている
    - dockerが動いている様子はあるが
    - 見せれるほどのものでもない
- k, それは中間でもあるとより良いと思ったが，最終でまとめればいいかと思った
- k, それより, どう言う登場人物があって、という説明がない
- k, P2で目標ってあるけど
- k, なにとなにがあって、どっからなにがこうげきするのかっていう説明がない。
- k, 4つの攻撃方法が書いてあるけど，
- k, これはどう言うパケットを生成して
- k, どういうことを狙った攻撃家の説明がないよね
- k, これが最終的にこう言う時脆弱性があるという
- k, 議論展開するならその説明が無いと何も議論
- k, 何も議論ができない。
- k, 検知手法の方で機械学習とかだったらまだ重要度が下がるかもしれないけど
- k, それにしても登場人物の説明が無いとね．．っていう
- niwa, 最終までには何かしらこういうものが動いてっていう説明の図だったりとか、
- niwa、結果こういう検知がありましたとかあればいいかと
    - MQTT over QUICの通常のキャプチャの様子と、
    - 攻撃を実行した場合の結果を図示して見せればいいと思います．
- ni, 今後のやることがshファイルの作成なので
- ni, 今行ってくれたことが次やることだと思うので。
    - shファイルにした方がいいことは眞田くんから教えてもらった
    - いちいちこれを一つ一つ実行するのは手間なので、
    - パケットキャプチャして内容を見れるようにして
    - 解析した内容を将来的にはIDSに
    - パケットキャプチャを可視化できるようにして最終発表したい
- ni, ミニプロなのでshファイルに纏めるとかいう技術的な勉強をしてもいい
- ni, 取捨選択しながらやってください。
    - 正月なんかは時間があるので、成果が出せるといいなと思う。
- kat, 攻撃をすると言うけどそれを
- kat, どこでやるかを気を付ける必要があって
- kat, 外に仮に漏れちゃったり，他の研究室に流れるとまずいので，
- kat, やる時はclosedな外に漏れない状態でやる必要がある
- kat, この4つの攻撃では中間発表でしたデータセットの中身だよね．
- kat, このデータセットはpcapがあったよね
    - pcapがあります。
- kat, pcapがあるから，それが単純に使えるかはわからないけど
- kat, tcp reply?と言うソフトウェアがある
- kat, そのソフトを使うとpcapデータからheader部だけ書き換えて
- kat, ローカルでpcapを流してくれるので
- kat, それでいいかはわからないけど、攻撃のところをいちいち実装しなくてもいいのかなと思った。
    - 確かに攻撃?...
    - MQTT over QUIC独自の攻撃なので，そこは差分を見つけて自分で実装するかとか考えてます
- katm プロトコルはTCPと同じなら、使えるんじゃないかな。
- k, これは攻撃の検知をやろうとしているのか
- k, 実際に攻撃しようとしてるのかでいうと攻撃しようとしてるよね
- k, 過去の攻撃をキャプチャしたものを流しても
- k、基本的には攻撃にはならないんだと思うんだけど、
- k, 目論見になっているのかな?
- kat, ひとみくんは攻撃を検知したいのか攻撃を作りたいのかどっち？
    - ミニプロジェクトでは攻撃を作る方をやりたい
- kat, であれば、単純にrelyではなくてもいいか
- kat, 一から実装する？
    - 攻撃用のライブラリがあって
    - 攻撃用のライブラリで
    - kali　linuxとかを使って攻撃できるのではないかと思う。
    - おそらくできるんじゃないかなというのが今の目論見
    - そこを調べるのもミニプロの一つの目標
    - 現在調査不足で
    - MQTTに対してライブラリベースで攻撃できる
    - そのライブラリがmqtt over quicにそのまま応用できるかはわからない
    - それを実際に自分で構築したmqtt over quicに実装して
    - 試してパケットの様子を観測しつつそれが
    - これができたならなぜできたのかを考えて発表するか
    - できなかったらできなかった理由をパケットキャプチャの
    - データベースを元に考察できればいいんじゃないかと思ってる
- kat, 今の話からするとミニプロのゴールは
- kat, 人見くんが作ったMQTT over QUICのシステムに対して自分で構築した攻撃を行った結果どんなことが発生するかを観測することが目的？
    - 今のところはそれが目標だと考えている
    - その知見をもとにIDSにつなげたいと思っている。
- a, P8 クライアントが無いって行ってたけど，
- a, クライアント型の実装があるとしたら何がある？
    - erlangとcがあって、
    - ないわけではないがスターがあんまりついてなかったり
    - README通りにやっても動作しなかった。
    - 少なくともelangとcはできる
- a, 実装が多くない理由はなんでだろう?
    - Cとerlang だけで十分
    - iot的な用途で言うと軽いプロトコルでいいので
    - それで満足している人が多いのかと思う。
    - mqtt over quicが新しいことも含めて
- a, それってライブラリとしての実装がないってこと？
    - mqtt over quic のライブラリとしての実装ですか？
- a, そう。
    - ライブラリとしては、モスキートの中にはないと思う。
    - 少なくとも　emqxは実装があって
    - それを見た範囲だと上記の2つとpython, javaで実装がある．
    - githubのスターが多い順に、erlang, c　...だった。
- a, よくわからなくなった. 
- a, 実装っていうのは，クライアントっていうのはIoTのエッジの端末に入れるものだと思ってて
- a, それは作らないとそれぞれのiotのアプリケーションで実装することになると思うんだけど
- a, EMQXがプラットフォームなのかなんなのかって話だけど、
- a, ブローカとかは共通実装で作り込まれていて、インストールするだけでいいと思うのだけど
- a, publisherていうのはアプリケーション毎に
- a, ラズパイとか決まったセンサを....とかどのレベルでないの?
- 
- a, 実装がないと言う言葉の意味がわからない
- a, pythonとか, erlangとかいろんな実装がemqxでできるようになっているとあったが
- a, ブローカーはサーバ側なので何でも同じ仕様だと思うので
- a, 最初から実行ファイルが出来上がってるかソースコードが提供されていると思うが
- a, クライアントはiotを想定すると, かなり多様なデバイスで動くので
- a, 汎用的なクライントツールを提供する意味がないと思う
- a, なので、この言語を使いたい人はこのライブラリをという
- a, ライブラリを揃えておしまいな気がするので
- a, publisherかな．
- a, MQTTに対してはそれぐらいの認識はあると思うけど
- a, pub/subモデルやったことある人はその認識がある
- a, その時に実装がないって言われると
- a, ライブラリが無いと言ってるのかライブラリを活用したツールが無いかがわからない
    - どちらかというとライブラリがない方で
    - QUICの実装がpythonであって，
    - それを拡張として取り込んで実装されている
    - ライブラリにQUICを取り込んだものは無い
    - 個々の実装に対して各言語のQUICを取り込ませて
    - そのサンプルプログラムが実装して
- a, EMQXの定義がわからない
    - もすきーとのブローカーの昨日に加えてより高機能になったもの
- a, ネットワークの階層のプロトコルはQUICに特化していないってこと？
    - それは設定で帰る
    - QUICにするならQUICの環境を作らないといけない
- a, クライアント側のライブラリがTCPベースのものがよくされていて
- a, 実装は一部の言語しか対応していないってこと？
- a, ライブラリまで実装したいのかっていうのもあるけど
- a, あるものを使うか，欲しい物がなければ自分で作るかのどっちかになりそうだね
    - そこを試行錯誤中です
- a, まずは最初はテストする必要があるから、
- a, あまり言語を選ばずに
- a, あるものを使えばいいと思う
- a, 攻撃の実験は気をつけてください。
- a, 単独でやらずに周りに相談しながらやってください。気をつけて
    - 法律周りはまた先生方に相談させていただきます
- oh, このMQTTクライアントツールに`--enable-quic`オプションとかあるけど、これでとりあえずテストできそうだけど、、
- oh, mqtt over quicの通信て一度は試したの？
    - まだ試せていない
    - だから、HTTP3の通信でいろいろ試そうと思う。
- oh, チャットに貼ったけどこのツールも調べたと思うけど
- oh, これでとりあえずQUICのテストメッセージが送れると思うから
- oh, これができないと話にならないから
- oh, まずはそれを試そうと思うのと、
- oh, 攻撃をkaliでできればいいって行ったけど直感的に無理な気がする
- oh, そんなに難しくないから多分攻撃ツールを作る必要があって
- oh, なので、テストメッセージが送れたら、
- oh, 送信したメッセージを沢山送信するツールとか
- oh, スキャンするツールに変えていくのが定石な気がする。
    - テストを送ってそういったものを大量に送信するものとかスキャンするものとか作っていきたいですね。ミニプロなのでツールを作っていきたい。
- oh, スライドがやや簡素すぎるので、丹羽くんも行ってたけど、図とか絵とか欲しいなと思いました。
    - 最終発表では登場人物も図にまとめていきたい
- k、用語は正確に
- k, HTTP3はHTTP/3とか
- k, openSSLはSSLだけ大文字とか
- k, QUICは全部大文字なんだけど、一部そうじゃなかった。
- k, そのへんを気をつけないと
- k, 気にしてない人は気にしてないけど
    - その辺りはちゃんとやっていきたい
- mat, erlangの読み方はアーランと読む
- mat, データが消えたってことを言ったけどそれは消さない努力をしましょう
- mat, 実験結果は残しましょう
    - ミニプロの進捗とかで見せたものですね
- mat, データの管理の仕方は困ったらファイル名は日付でもいいので、
- mat, 時間から遡れるようにしたほうが条件が悪かったとしても残しておいたほうがいい．
- mat, こういう発表のときもちょっとでも意味がありそうだったら共有してもらえると，何かアドバイスできるかも


## 眞田
- ni, p9の実験というのは、
- ni, これは何を予測して、精度がこうなった？
    - 説明変数はAPのRSSI
    - 目的変数はX,YであるZは対象外
    - で学習して、
    - データサンプルがこれだけあったものを
    - ファイブフォルドで学習等を行なった
    - 上の値はその平均
- ni, ってことは、RSSIの値から、
- ni, XYは三次元方向を考えずに二次元で
- ni, 部屋のどの位置かと予測したもの
- ni, 三次元は厳しそうなので…
- ni, この図だとスタートは0，0のところ？
    - 上の点の方
- ni, 本来であれば同じ位置にいるはずだけど別の場所にいる
    - 補正できればと考えている
- ni, ０.８とかのスコアが出てたけど、
    - メートルです
- ni, 1m以内の誤差がでてるのか
- k, 一周した時の誤差？
- k、　今の場所がどこって言った時の誤差？
    - APのデータから位置を予測して
    - その位置と本当の位置の誤差を示していると感じている
    - 論文を見てきたんだけど、
    - CDFとかのグラフを吐き出してみる方が良かった
- ni, 本題ではない実験？
    - そうです
- ni, 実験をやったのであれば、何をやったのかを書いておいてくれないとわからないので、書いておきましょう。
- ni, 1mくらいの誤差でAPからの情報を使っては出せそうなんだね
    - 結構、学校のアクセスポイントの定義は
    - おそらく，パケット解析のけっか，
    - 学校は至る所にアクセスポイントがあるんだけど、
    - 同じapでも
    - macとSSIDが異なる
    - ルータは基本的には同じmacアドレスだと思ってて
- k, SSIDには、
- k, BSSIDとESSIDがあって
- k、一つの無線のネットワークを一つのアクセスポイントから提供する場合は、
- k, 各基地局がBSSIDを持っているが
- k, 共通してESSIDを使ってる
- k, BSSID毎に1つのmacアドレスが必要
- k, それが他の基地局で、共通していても
- k、　BSSIDが異なれば、異なるMacアドレスだし、
- k, 1つの基地局で複数のSSIDを出す設定をしてる
- k, SSIDごとに別のSSIDが必要になってくる
- k, さらにいうと，2.4GHz帯と5GHz帯で
- k、　別々のMACアドレスを使っているシステムもある。
- k, 今のラッカスがどうなってるかは知らない
- k, 組み合わせは様々
    - P8は愚直にやってるが
    - アクセスポイントを定義する際に、
    - 同じAPだろうっていうところを束ねてやってる
- ni, mmは同じ名前でたくさん基地局があるだろうし
- ni, 違法な基地局がいっぱいあるだろうし...
- k、基地局は？？のシステムなんだけど、何を持ってルーターって言ってる？
    - 基地局が正しい
    - 同じ基地局からでているであろうBSSIDをlistに束ねたっていう感じ
- k, 1番の中の1,2は、どうして同じだと判断したのか
    - 学内のアクセスポイントマップが公開されているが、
    - それを確認してmacアドレスが公開されていて，
    - そこで共通する部分がある点と
    - RSSIの値が同じということくらい。
- k, なんとなくこれを見ると規則性があるとおもう
- k, うまくまとめて、このような理由があると思うと述べれれば良いと思う
- k, 最終バイトは奇数と偶数のペアが2つあるかもしれないってことよね
- k, 2.4GHzだけ取ってる？
    - 両方取ってる
- k, 2.4Ghzが偶数で、
- k, 5Gが奇数かもしれない
- k、そういうところで出せるかもしれない
- k, センターに聞いたら教えてくれるかもしれない
- k, 同じ基地局だったら，
- k, BSSIDが異なってもRSSIが同じだったって話？
    - RSSIとデータの吐かれるタイミングが連続していた
- k, RSSIが同じってことは2.4GHz帯と5GHz帯が同じってことは無いね
- k, enter priseの基地局だったらよくあること
    - ここでもヒューマンエラーが起きているのかもしれないといった形
- k, ヒューマンエラーを恐れるなら、あえて束ねないのもあり、
- k, 理由として、サンプルが少なすぎる？
    - 束ねないっていうのは、p8のnがすごく大きくなるということ？
- k, 学習が大変になる？
    - 学習も大変だし，
    - 実用的なところだと
    - どれくらいの次元数があったらまずいのかわからないけど
    - その場で位置を推定する場合、
    - 次元数が多すぎるとシステムとして、推定時間が有効には羽田らかない
    - 今挙げたすべてのAPでやるとデータのサンプルも少なくなるし，
    - 計算時間もかかっちゃうのかなと思います
- k, そういった根拠を示してやってくれるといいよね
- a, ROSって説明としてあっていたか
- a, ROSってどういう意味で説明してた？
    - ROSを出していたのUbuntu周り
- a, SLAMといい間違えてるんじゃないかなと思うくらい
- a, Linuxのインストールの話でも度々出てたから
    - p11とかですかね？
    - キャリブレーションを行うためのタグなので、
    - ROSと無縁では無いがROSという単語を使わなくてよかったかも
- a, あくまでslamの精度を良くするために使ってみたいという話だよね？
- a, そのエイプリルタグの読み取り結果がROS上で流れてくるかもしれないが
- a, ROSはあくまでプラットフォームの名前なので
- a, 今日は機械学習の議論が盛んになってたけど，
- a, さっきの次元数の話だと，次元削減のアルゴリズムもあるので興味があった調査してみて
- a, 自分で手作業でやらなくても
- a, ???とかすると勝手にいい特徴量だけを選んでくれるので
    - 特徴量削減の話は、
    - 音でやる話もしたのでそこで調査する必要があるので
    - それに付随してやっていこうと思う
        - (大平)ReliefFってアルゴリズムで、簡単に良い特徴ランク付けできるので、おすすめす
- a, 過学習しているかもという判断は、
- a, とってるデータの特性を考えて、
- a, 過学習かどうか評価できるかも検討しないとね
- a, 1回研究室一周していただけのデータでは、
- a, それが過学習かどうかも判断できない。
- a, 変動要因がわからない。時間で変動してるかもしれないし、人で変動しているかもしれない。
- a, 電波だったら人とか他の通信の状況とかあるので
- a, そういう状況を変えたデータを多様に集めないと過学習が起こりやすいデータになってしまう
- a, テストデータはやっぱりそういう全く異なるタイミングで取ったデータを使わないとわからない
- kat, 次元数の数を減らしてリアルタイムって話があったけど
- kat, 目指しているのは、精度の向上か、速度の向上か？
    - 精度ではあるが
    - あまりにも次元数が多いのは良くないと思ってて
    - あまりにもの範囲がわかってないけど.
- kat, とりあえず目指してるのは精度の向上で，その上で
- kat, 速度という文面も加味できればと考えているということか
- yam, p8のところで，APとMACアドレスのところ
- yam, APの中で絶対これはここだっていう自身があるのはあるのか？
- yam, 例えば、自分の研究室の中のやつとか。
- yam, そういう確実にわかるものが３つとかあるなら，それだけを利用するのもありなのかなと思った
- yam, APの数を確実なものだけを特徴量として使用したほうが
- yam, 手作業のミスやノイズも無くなるのでは？
- yam, そんなにアクセスポイントは多くなくてもいいのかと思う。
    - 一応、下の方の１１とかは、上のほうが自信がある（番号で言うと）
    - 信頼性が低いのはデータとして省いてたりもした
    -　データとしては、１０個ぐらい使っていた 
- yam，機械的にどの特徴量を使うかは分けることができるので
- yam, 結果から見て、自信があると逆算できるのではないかと思った
- yam, 適当にjobを突っ込めば数時間で終わるので実践的に小規模計算サーバをつかってもいいと思う
- k, BSSIDのリストは基地局ごとに取ることはできるが
- k, すべての基地局の基地局ごとのBSSIDのlistを
- k, 一括でとる方法はわからない
- k, 後で一緒に見に行ったらわかるけど，結構変な組み合わせがある
- amt, B棟だけで
- k, Bだけで21個あるのは十分多いでしょ
- ni, １huroaでも３台以上あるし、inet以外にも色々ありそうだと思っている
    - inetのやつは後からSSIDで省いたりしてる．
    - どこでもあるやつだけ残している
- mat, 出している人の負担も考えつつ、出してもらえるものなら出してもらった方が良いかも
- k, 第4オクテットの1桁目はバラバラだけど
- k, 二桁目は揃っている、第５オクテットも揃っている
- k, 台6オクテットは2.4と5であって5Gのほうが足らなくってa9までいってる
- yam, 取得する周波数帯を制限したらふるい分けれる気がするけど
- yam, 今は、ホッピングさせているが、それをさせない方が重複がないと感じたか
- k, 基地局がマルチESSIDを使ってるので，１つの基地局で複数のMACアドレスを持ってます
- k, 1番ってなってるのが准教授室の廊下にあるところ
- k, 2.4GHzにあるMACアドレスは、７つあるはずだが、４つしかないので、何かが漏れている
- mat, このデータは使いたいのでA,Bのリストを
- mat, できればA棟B棟全部出してもらえると…
- k, 基地局のコントローラーの管理者権限がいる...
- mat, この値はわかっている方が嬉しい
- k, コマンドとかインタフェースがあるかと思ったが，一括では出せない
- k, データ一覧だと基地局の一覧は見れる、そこからBSSIDができるが、そこからコピーペーストでしかできない。
- a, ibeaconのSSID一覧がitcから公開されている．https://itcw3.naist.jp/ITC-local/iBeacon/ibeacon.html
- a, 古い情報だから更新しないといけないけど…基地局の設置位置自体は変わってないはず
- a, 基地局のusbポートを借りたものと
- a, コンセントに直接挿してるものがあるはず
- a, メンテナンスする必要はありそう.
- k, 六桁はラッカス固定で
- k, 7桁目をスキップして
- k, 8,9,10,11の4桁でほぼほぼ機器が固定できる
- k、 7 と 16桁目が基地局の中で変わっている
- k, 先頭の４びっとと末尾の４ビットが変わっていっていて
- k, 2.4の塊と5GHzの塊は変えないとSSIDは違いますとなっている
- k, 2.4が一番最後の4bitが...が多い
- k, 5Gはcが多いみたい
- mat, 取れそうな形である
- mat, B2のデータで様子見

## そのた
- mat, NAISTの正確な図面ってありますか？
- a, 聞いてない，ごめん
- mat, 昔一回問い合わせたら断られた
- k, 学内のマップがほしい？
- k, CADの生データは出せないことになっている，少なくとも業者には出せない
- k, 施設課の藤原さん？に聞いてみるしか無い
- a, 研究で学内で利用したいというともしかしたら
- k, 縦横比があっていないからもっと正確な値が欲しい
- mat, 正確な図面がもらえるなら嬉しい
- a, 指摘事項ください
- mat, 今のデータのどこが間違っていると言うところをまとめておきたい
- 
- 
- 
- 
- 
- 
- 
- a