日本からipv4only.arpaへの名前解決が大量に送られてるっぽい

DNS network

一番下に追記あり。

ipv4only.arpa への名前解決

Cloudflareの1.1.1.1を使ったドメインランキングを眺めていたら人気でないはずのドメインが日本国内ランキングで上位に。

ipv4only.arpaへの名前解決が大量に。

Image

https://radar.cloudflare.com/domains/domain/ipv4only.arpa

https://radar.cloudflare.com/domains/jp

51位にあった amazon.co.jp より高い位置に。

確実にネットワーク機器か何かソフトウェアが行っているDNS。（ランキング上位はそのようなものがどっちみち多いが）

でも日本だけ多いのがとても不思議。

ipv4only arpaの名前解決をそんなに大量にするってどんな状況だろうか？

ipv4only arpaのAAAAクエリの名前解決はDNS64 (及びNAT64) がネットワークにあるか探す行為。

datatracker.ietf.org

追記：（言葉足らずではてブで説明してくださってる方がいた）

日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ

前提・自明として書かれてないけど、ipv4only.arpa.は文字通りipv4のみのAレコード192.0.0.170と171、これをAAAAで聞きに行った返答内容（なしと返るか、返るにしてもどんな合成ipv6が返るか）をみてDNS64対応状況をみるんだね。

2023/09/30 09:51

b.hatena.ne.jp

Chromeに昔これを使ってNAT64配下でのCLAT機能を実装した。

momoka0122y.hatenablog.com

ipv4only arpaのAAAAクエリの名前解決はDNS64 (及びNAT64) がネットワークにあるか探す行為。  
それをしてるソフトウェアかネットワーク機器が日本から大量の名前解決をしてそう。

しかしなぜこんなに大量なんだろうか。

上のChromeにNAT64配下でのCLAT機能を実装したときはまず、IPv4ソケットは作れないけどIPv6ソケットは作れるという状況のときのみ機能が発動するようにした。（そしてIPv6オンリーであることは稀なので大量の名前解決は起きないようにしてある（無駄なので）。

このDNSクエリを投げているソフトウェア、ネットワーク機器を見つけたいですね。

昔ipv4only arpaへの名前解決をtcpdumpか何かで見かけたことある気がする。（気がするだけかも）

関連してそうだけどあまり情報を得られなかったリンク先

Sudden jump in requests to ‘ipv4only.arpa’ from iPhone and Apple Watch : dns

 

以下色々追記：　（反応ありがたいです）

 

 

日本国内から多いってことはIPv6オンリー環境からたくさん問い合わせが起きているのだろうという予想していた。↓の人と同じく。

日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ

ドコモが2022年からIPv6シングルスタックを提供していることと関係ある？？？

2023/09/30 10:45

b.hatena.ne.jp

 

しかしその条件は必要条件ではなさそうだった。

 

 

いろんなところでipv4only arpa へのクエリがたくさん観測されている。

それならなぜ日本でこんなに多いのだろうか？

日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ

Cloudflareだけなのか、他のPublic DNSでも同じなのか気になる。日本国内とするとアイオーとかエレコム？

2023/09/30 10:05

b.hatena.ne.jp

Public DNS で観測されたというのが個人的に結構驚きポイント。　IPv6only環境ならDNS64がISPによって用意されて（用意されていなくても）そのISPのリゾルバを使うようにネットワーク設定がされていることが多い気がする。

ISPがリゾルバ用意していなくてPublic DNSを使わせているのも全然ありえるけど。

↑考えてみれば上の驚きポイントはIPv6onlyというネットワーク前提が必要だと思っていたけど、他の人がdual stackでもクエリを見つけていたので、別にPublic DNSに聞いているのはそんなに不思議でもない。

Google Public DNS64  |  Google for Developers

Public DNS64 一覧 - Qiita

 

まとめると、

「日本でのみ（台湾も多い）ipv4only.arpa のDNS問い合わせが多い」かつ「でもIPv6onlyでなくても観測される」のが不思議。

日本が特別な理由がわからない。

モバイルのみとかならわかるんだけど。

it.srad.jp

追記：

まだmacOSでしか検証できていないですが、LINEの可能性がとても高い。

LINEを停めている状態でtcpdumpしてinterface up down してもなにも見つけれなかったが、LINEを起動している状態でtcpdumpしてinterface up downしたら見事ipv4only.arpaの名前解決が発見された。そしてこれが日本と台湾で多い理由もLINEと説明がつく。

（LINEを起動した瞬間の`tcpdump udp port 53`の結果。ipv4only.arpa がLINE関連のドメインに挟まれている）

JANOGの資料に日本と台湾でLINEのIPv6対応の話がされていた。

「LINE」をIPv4/IPv6 Dual Stack環境に変更した話

日本と台湾で多いことの説明がつく。（そして逆にタイとインドネシアがランクインしていないことも説明つく）

ここでLINEが大量のipv4only.arpaの名前解決をしていると仮定してなぜしているか以下の理由が想像できる。

  • LINEアプリ内部でNAT64プレフィックスを知りたい理由がある。
    • つまりDNS64を活用できない（DNSに登録されていない）ハードコーディングされたIPv4アドレスがある。
    • それにパケットを送るためにCLATの実装がされていて、NAT64prefix::宛先IPv4アドレス　というIPv6アドレスへパケットを投げたい。
    • しかし、このクエリはIPv4オンリーの環境でもdual stackの環境でも観測された。CLATがしたいならIPv6-onlyのときのみ行えば良いのではないだろうか？
  • NAT64プレフィックスを使うわけではないけど、NAT64があるのか知りたい。
    • 上と同じく、このクエリはIPv4オンリーの環境でもdual stackの環境でも観測された。CLATがしたいならIPv6-onlyのときのみ行えば良いのではないだろうか？

うーん。

一番目の場合ならDNS使えないのかと思うのと、

そもそもIPv6 socketしか作成できないかどうかの確認を事前に行えば本当に必要だった時のみクエリを出せるからその確認をしないのがよくわからない。ネットワーク的にIPv6-onlyだたっとしてもOSのCLATの機能によりアプリケーション目線ではdual-stackに見えることはよくあると思うので。

LINEのアプリケーション側でIPv6対応した時にどのような設定をいれたのかとても気になります。👀

（もしLINE関係なく観測ミスだった場合は大変申し訳ございません）

docs.google.com

追記2：

JANOGで発表した後のコメントから。

確かに、考えてみればP2Pするなら、アドレス直書きする必要があった。完全に見落としていた。恥ずかしい。

 

exmaple.comというtypoドメインを持ってるcloudflareの分析を読んだ

network DNS 最近読んだ記事メモ

Typo traps: analyzing traffic to exmaple.com (or is it example.com?)　

以下のCloudflare blog を読んだ感想。

blog.cloudflare.com

Cloudflareが exmaple.com もってて、それに関連したtypoの話。

exmaple.com にくる通信の99.99%がbot由来らしい。

日本からだとAS17676 SoftBank からと http://exmaple.com へ大量のbot通信が流れているらしい。これはルータか何かしらのソフトウェアかネットワーク設定でexample.comに行くはずの通信がtypoによって間違って設定されているのが理由と考えられる。

% curl https://exmaple.com/
<h1>Well hello there.</h1>
<p>
Welcome to exmaple.com.
<br>Chances are you got here by mistake (example.com, anyone?)</p>

ちなみに exmaple.com の tranco-list でのsubdomain込みでのリストでの順位は 281548位　だった。2023/09/24所得でのリスト。

参考に他のドメインのランキング

36位          wikipedia.org
38位          root-servers.net
281位        example.com               <----  本家
437位.       yahoo.co.jp
3516位      hatena.ne.jp
5618位      ipv4only.arpa　　　 
6035位　  b.hatena.ne.jp
47537位    hatenablog.jp
65030位    hatenadiary.jp
110534位   blog.hatena.ne.jp
186643位  www.example.com
284055位  kobegakuin.ac.jp
281548位   exmaple.com               <----  ここ
285470位  d.hatena.ne.jp
969749位  www.hatena.ne.jp

これはtranco-list を使用した物だが、Cloudflareの1.1.1.1を使用したランキングも

https://radar.cloudflare.com/domains から見える。

example.comをどこが1.1.1.1を使って名前解決してるかの情報。

google.comをどこが1.1.1.1を使って名前解決してるかの情報。
日本結構1.1.1.1 使ってるんだろうな。1.1.1.1でgoogleを名前解決したうちの17.3%が日本か。

 

最近読んだ記事メモ (Fiber Network, BIRD, Netmaker, default outgoing IP, sadservers.com, inet-henge)

最近読んだ記事メモ

 

Our Global Fiber Network, AS1299 - Arelion

https://www.arelion.com/our-network#interactivemap

Arelionのケーブルの地図が眺める。

 

Upgrade Now! BIRD 1 EoL This Year (2023) - FullCtl

https://www.fullctl.com/blog/BIRD1EoL

BGP routing daemon BIRD の version 1 のナンバリングが  1.6.8.　でおわる。BIRD 2に移行するように勧められている。

BIRDはkernel packet forwarding tableを管理するために使うことができるソフトウェア。Linux kernel (included in distros such as Debian, Ubuntu, and Fedora) や BSD 系 (tested on FreeBSD, NetBSD and OpenBSD)　で使用することができ、RIP, RIPng, OSPFv2 v3, BGP, BFD, NDP/RAなどのルーティングプロトコルに対応している。

プログラム可能なroute filterがあるため、多くのIX / IXPで route server のソフトウェアとして使用されている。（2012 Euro-IX survey で BIRD がヨーロッパのIXの中でもっとも活用されているroute serverと記録）

BIRD 2によってBIRDはより良いものになる。BIRD 1.x ではIPv4/IPv6r両方に対応していたが、別々にコンパイルする必要があったがBIRD2ではその必要がないなど、BIRD2を使用することでより良い機能を使用することができるようになる。

 

Netmaker

www.netmaker.io

WireGuard VPN ツール。TailScaleより5倍はやいと言っている。

こんど試してみよう。

tailscaleとの比較の図。

https://www.netmaker.io/resources/tailscale-vs-wireguard

 

Best way to get default outgoing IP address on Linux　JUL 27, 2023

pavel.network

複数のインターフェースがある場合にどれが選ばれるかは、`ip route get [address]` で知ることができるが、他に方法はないか？

linux kernelコードを読んで、__ip4_datagram_connect() でソケットが使用するソースアドレスを選び決定していることがわかる。connect() して getsockname() することで、実際にパケットを外に出さないでどのアドレスが使用されるか調べることができる。

記事のコメントによるとiproute2 ~4.14 (2017)から json output が 対応されているため

# ip -j r get 8.8.8.8 | jq '.[0]["prefsrc"]'
"203.178.135.104"

のようにして取得して、変なパーサを書かなくても済むらしい。

#  ip -j r get 8.8.8.8
[{"dst":"8.8.8.8","gateway":"203.178.135.1","dev":"enx7403bd7fa265","prefsrc":"203.178.135.104","flags":[],"uid":1000,"cache":[]}]

ip コマンド -j で json出力知らなかった。

 

sadservers.com

SadServers - Troubleshooting Linux Servers

sadservers.com

最初の一問解いて勉強になった。解き方を知っていてもヒントのこれを使うというコマンドをしらなくて勉強になった。20問あるっぽい。

 

devops-exercises

github.com

同じく勉強系でGitHubに乗ってる問題集。良さげ。

 

PWDX(1)

NAME
       pwdx - report current working directory of a process

SYNOPSIS
       pwdx [options] pid [...]

今まで知らなかった。便利。

 

saf

github.com

saf is a simple, reliable, rsync-based, battle tested, well rounded backup system, written in Python.

 

IETF 117 San Franciscoにリモート参加しました 　ーうなすけ　2023年08月27日

blog.unasuke.com

うなすけさんのIETF117のまとめブログ。QUIC, TLS, Moq, mls, ccwg, あたりの議論についてまとめられている。

 

inet-henge

github.com

ネットワークトポロジーを描画ずるためのツール。便利。

DemoLink： 

https://codeout.github.io/inet-henge/shownet2016.html

見本画像。

 

想定された使い方ではないだろうけど、mtrをたくさんうってそれを視覚化するのをこれを使って作った。

http://203.178.135.104:8000/top-jp-17931maholova/

一時的にここに置いておく(動いていない可能性あり）。このmtrを視覚化するコードちゃんとまとめて公開したい。ネットワーク初心者にASを通っている様子を見せるにいいかなって。

最近読んだ記事メモ (DNS Operations, Load Balancing, Wireshark, Kubernetes)

最近読んだ記事メモ

 

DNSリゾルバの運用コスト削減への道　ヤフー株式会社 針⼭ 拓海

www.janog.gr.jp

スライド：　

https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-dnscost-hariyama.pdf

クエリのログをとるため300台もDNSサーバがある。
拠点や⽤途ごとにVIPを建て、物理サーバをVIPメンバに収容する構成
• ロードバランサを使⽤、L2DSR/L3DSR/L4 Inline構成

環境ごとにVIPネットワークの構成が違う
- DSR(Direct server return) のVIP構成を中心に構築
- リスポンスはLBを通らない方がLBコストがよい

resolv.confを変更してリプレイスを行う。
- 新しいアドレスはACL大丈夫か？

＞static route 出し分け発狂しそう
そうです。。撲滅しました。

Q. リソルバのリプレイスにおいて、DNSサーバのIPアドレスを変えるのではなく、resolv.conf書き換えを行った理由は？
A. （あまりよくわからなかった）L2DSRの場合は同じネットワークのVIPとサーバが切り離せないので、新コアスイッチに古いIPアドレスを付けた場合は広報されるまでそのネットワークはダウンされ、同じコアスイッチの下にいる同じvlanのクライアントは新しい方にリクエストを送り、新しいリゾルバが外との疎通性ができる前にリクエストを受け付けてしまい問題がおきるため行わなかった。

Q. BIND脱却は？
A. BINDのみに実装されている機能に依存しているため、脱却がむづかしいためアプライアンスとの二段構成になっている。
A. 逆にBINDはTTLが2以下だと勝手に破棄する。これは困るというのもアプライアンスを使う理由の一つ。
やっぱりBINDは脆弱性がいっぱいあって、使っている人はみな苦労しますね。

Q. クエリログをとっているためサーバが大変。みなさんスケールするためにそうしてますか？監視サーバのディスクが溢れてしまったことがあり。。。
A. （会場から）力づくです。dnstapもしてる。ログ自体はそこまで多いわけではなくなんとかいけてる。Dosされたら困る。
われわれもDNS tapやりたいがそれを漏らしたら怖い。
A. （会場から　さくら）自分たちもやっているが、確かにディスクIOが厳しくなるが、その前にリゾルバのNICのカードに制限が先にくるためカーネル含めて、なのでクエリログのディスクIOはそれほど大きくないため、別のインターフェースを立てて1日一回rsyncしてとってきている。処理性能はCPU使うがCPUは足りているので力づくでいけてる。
A. （情報通信研究機構）NTPサーバだが10億きている。すいっちのmirror port を使って通信を10秒単位のファイルでNASに入れている。別のサーバで複数代のサーバでパケットを見ている。
A. dnstapを使っている。とったらすぐログサーバに入れていてリゾルバにはためていない。キャッシュサーバよりこのログサーバの方がお金がかかっているぐらいで正直ログとりしたくない

Q. 　どのように分けているか。
A.　プライマリー、セカンダリーは同じ設定を二つ作り、クライアントのIP偶数奇数などで、配布する設定を分けている。


感想。
半分の時間がマイクタイムで、いろいろな運用者の意見がマイクで話され“meeting” という感じで聞いてて面白かった。
ログの話が活発だった。dnstapoを多くの人が使っているのを知った。試してみたい。

 

InternetWeek2018　DNS Day　IIJ

収集の仕方について分類紹介。

 

DNSの可視化検討　NTTコミュニケーションズ株式会社

2022年1月27日　小坂 良太

docomoでのDNSの可視化の話

フルサービスリゾルバのロードバランサーなし構成について　NTTコミュニケーションズ株式会社 小坂 良太

DNSのLBを無くした時の構成。

BFD　(Bidirectional Forwarding Detection　ルータ間で相互にpingを打ち合うようなプロトコルでmsオーダーで断検知が可能、L2スイッチを超えて断検知が可能）

ルータでBGPのタイムアウトより先に通信断を検知するためのBFDをDNSサーバの疎通確認に使用。サーバで使用するためにFRRを使用。

Red Hat's open source rot took root when IBM walked in - The Register

https://www.theregister.com/2023/07/07/red_hat_open_source/

Fri 7 Jul 2023

https://www.similartech.com/ によるとRHELの10倍CentOSはビジネスで使用されているらしい。

2005年までCentOSは最新版を使いたい人はRHELを使うように勧めていたが、RedHatがCentOSをトレードマークの侵害で訴えたところCentOSはRedHatを名指しすることを一歳やめ"with Prominent North American Enterprise Linux Vendor."とだけいうようになった。

2014年にCentOSを手に入れたが意味がなく、2020年にCentOS StreamをはじめCentOSを止めた。

これによって代わりとして AlmaLinux と Rocky Linuxが出現することとなった。

 

Wireshark Is 25: The email that started it all and the lessons learned along the way - Wireshark Blog

https://blog.wireshark.org/2023/07/wireshark-is-25/

Gerald CombsがWiresharkの25年の歴史を振り返ってOSSが栄えるために必要なものを挙げる。最初はEtherealという名前だった。

 

SUSE To Go Private　

August 17, 2023

https://opensourcewatch.beehiiv.com/p/suse-go-private

SUSEは株主の影響を受けないように公開株式をやめる。
> aims to merge the company from the Frankfurt Stock Exchange into an unlisted Luxembourg S.A. entity.

これによって世の中に影響を受けずに長期的に計画を立てることができることを期待する。

 

Adopting Istio for a multi-tenant Kubernetes cluster in Production

https://medium.com/mercari-engineering/adopting-istio-for-a-multi-tenant-kubernetes-cluster-in-production-df1a8260ca24

Aug 28, 2019

メルカリはmulti-tenant single Kubernetes clusterを使用している。その話。

やる理由の一つとしてgRPC load-balancingがある。gRPC は HTTP2 の multiplexing をしようして RPC callsおくるため、L3で動作するk8sではうまくロードバアrんシングすることができない。

service meshを導入してproxy sidecarを使用することで解決する。

話されたことの一部

 

- 障害への対応
Istioのコントロール・プレーンの何かがダウンした場合、クラスタ全体に大きな影響が出ないようにする必要がある。

 

- istio-proxy Lifecycle

istio-proxyはsidecar containerなので、メイン・アプリケーションの前に起動し、アプリケーションの後にシャットダウンする必要がある。

 

- Istio's Kubernetes Service Port-Name Convention

k8sはL4で動作するためistioaがsidecarを設定するために必要なL7を理解しない。

そのためistioは `<protocol>[-<suffix>]` のように名前づけをする。

この命名規則が守られているかをYAML validatorを用いて確かめている。

 

kube-vip

https://github.com/kube-vip/kube-vip

kube-vip provides both a floating or virtual IP address for your kubernetes cluster as well as load-balancing the incoming traffic to various control-plane replicas.

kube-vip を使用しない場合は（現在は）VIP用とロードバランサようで二つのソフトウェアを使用する必要がある。

VIP:　Keepalived、UCARP　など
LoadBalancing:　HAProxy、Nginx　など

最近読んだ記事メモ (Mastodon, Ultra Ethernet Consortium, Wi-Fi’s Future, Kevin Mitnick, BGP Path Attribute Filtering)

最近読んだ記事メモ

Watch Out, Fediverse Users: The FBI Can Seize a Mastodon Server - PC Mag
July 26, 2023

https://www.pcmag.com/news/watch-out-fediverse-users-the-fbi-can-seize-a-mastodon-server

Mastodonのような非中央集権形SNSは逆に司法に弱いかもしれない。

FBIがMastodonサーバのコピーを家宅調査の一環で徴収した。

警察はtwitterなどのテック大企業の場合はその会社に情報提供をお願いするが、Mastodonは非中央集権のためサーバの持ち主から直接そのサーバの情報を所得できてしまう。

Electronic Frontier Foundation (EFF) はFBIがとある団体のMastodon サーバのバックアップを応酬したことを警告している。
https://www.eff.org/deeplinks/2023/07/fbi-seizure-mastodon-server-wakeup-call-fediverse-users-and-hosts-protect-their


5月にFBIは"anarchist/anti-colonial" なグループKolektivaを家宅捜査した。
その時に8,000 以上active userがいるサーバのコピーも押収した。
データにはemail addresses, ユーザアカウント関連づけられるIPアドレス, hashed user passwordが含まれていた。

Kolektivaがホストしていたサーバのユーザは政府によってターゲットとされている層が多かった。今回家宅捜査の原因とは全く無関係のKolektivaサーバのMastodonユーザの個人情報がFBIの手に渡ってしまった可能性が高い。

大企業ではなく小さな団体によって運営されているMastodonは、個人情報が企業にマネタイズされない代わりに簡単に政府に押収されてしまう危険性がある。

FBIは記事の時点ではコメントを返していないため押収されたデータがどのように使われるかは謎である。

政府が合法な方法で情報を得たら、もとの捜査と全く関係ない事件の調査にもその情報を使うことができる。

Eugen Rochko Mastodonの創造者は以下のように述べる。
"The FBI performed a raid on one of the admins of kolektiva.social for unrelated charges, and that admin had a backup of the kolektiva.social database on one of their digital devices at home (not a recommended practice, for what it's worth). That Mastodon server is still up. Of course the FBI can take down a Mastodon server in their jurisdiction though, just like they can do with any other website. There's nothing special about Mastodon in that regard, just that taking down one server doesn't affect the rest of the network."


Leading Cloud Service, Semiconductor, and System Providers Unite to Form Ultra Ethernet Consortium - Linux Foundation
19 JULY 2023

https://www.linuxfoundation.org/press/announcing-ultra-ethernet-consortium-uec

Ultra Ethernet Consortium (UEC) は complete Ethernet-based communication stack architecture for high-performance networking　を作るために業界の企業の協力を集めている。

Ultra Ethernet Consortiumは　AMD, Arista, Broadcom, Cisco, Eviden (an Atos Business), HPE, Intel, Meta and Microsoft　をはじめとするネットワーク、AI、クラウド、コンピューティングなどに長年開発してきた企業である。

Dr. J Metz, Chair of the Ultra Ethernet ConsortiumはこれはEthernetをoverhaulしようとするのではなく特定のパフォーマンス要求のためにチューニングして性能を向上するのが目的。物理層からソフトウェアまでみて最善の方法でパフォーマンス向上を図る。

Physical Layer, Link Layer, Transport Layer and Software Layer
の4つのwgに分かれて行うらしい。

AI/MLの時代だが、標準化された、ベンダーニュートラルなデータセンターネットワークでパラレルアプリケーションに特化したものはない。


（これとIETFの関係性が何もわからない。こっちは企業が集まってるような感じなのかな？）

Talking Wi-Fi’s Future With David Coleman - wirednot

https://wirednot.wordpress.com/2023/07/14/talking-wi-fis-future-with-david-coleman/

David Coleman

筆者は自分がデプロイした6GHz に5％前後のクライアントがいるのを観測していて、いつこの数字は増えるのかと聞き、David Colemanは、Appleが次のiPhoneが6Eの対応をつけて（23年秋にごろと思われる）、低価格帯のAndriod端末も6Eのチップをしようすることで6GHzの使用が増えると見込まれると答えた。

6 GHZだとたくさんのチャネルを使用することができるため、一部をclient用チャネルから分けてmesh専用帯を作ることができ"high-throughput mesh backhaul"として使われる役割が期待できるらしい。

802.11ax (Wi-Fi 6)はもう4年あり、WLAN 7 はもうすぐ来る。

WiFiなにも知らないので、読んでても全然わからなかった。また今度読み直すか。


Kevin Mitnick Has Died Of Pancreatic Cancer - Dignity Memorial

https://www.dignitymemorial.com/obituaries/las-vegas-nv/kevin-mitnick-11371668
Kevin David Mitnick
AUGUST 6, 1963 – JULY 16, 2023

hacker legendらしい。

初めはハッキングなどの悪いことをして、少年院や刑務所に行くことが何度かあった。

FBIのMost Wanted Listに乗っていた話を書いたThe Ghost in the Wires: My Adventures as the World's Most Wanted Hackerをはじめ The Art of Deception, The Art of Intrusion, The Art of Invisibility
という本を執筆。

2000年に最後に牢屋から出てからはホワイトハッカーとして活動。Mitnick Security Consulting、KnowBe4で活動。

ほとんどの時間をGlobal Ghost Teamというpentesting team で活動。

 

BGP Path Attribute Filtering - A Powerful Tool to Mitigate Alien Attributes - RIPE Labs

https://labs.ripe.net/author/berislav_todorovic/bgp-path-attribute-filtering-a-powerful-tool-to-mitigate-alien-attributes/

BGP Path Attributesがプロトコルの変化によって種類が変わってきたけど、そのことによるルータの対応によってバグが起きてしまうって話。

そもそもBGPパスアトリビュートについては　ネットワークエンジニアとして　を引用。

www.infraexpert.com

　BGPで交換される4つのメッセージのうち、Updateメッセージがありましたが、Updateメッセージの中にパスアトリビュート（パス属性）が含まれています。パスアトリビュートはBGPで使用するメトリックです。このパスアトリビュートを組み合わせることで「AS」に対して様々な経路制御が可能となります。

　BGPの10種類以上あるパスアトリビュートは、大きく以下の4つのカテゴリーに分類することができます。

カテゴリー 説明
　Well-known mandatory（ 既知必須 ） 　全てのBGPルータで識別できて、全てのUpdateメッセージに含まれる
　Well-known discretionary（ 既知任意 ）　 　全てのBGPルータで識別できるが、Updateメッセージに含まれるかは任意
　Optional transitive（ オプション通知 ） 　全てのBGPルータで識別できない可能性があるが、BGPネイバーへは通知する
　Optional non-transitive（オプション非通知） 　全てのBGPルータで識別できない可能性があり、BGPネイバーへは通知しない


　BGPのパスアトリビュートには以下のようなものがあります。一番下の「Weight」はCisco独自の属性です。

タイプコード パスアトリビュート アトリビュートタイプ
1 ORIGIN Well-known mandatory
2 AS_PATH Well-known mandatory
3 NEXT_HOP Well-known mandatory
4 MULTI_EXIT_DISC Optional non-transitive
5 LOCAL_PREF Well-known discretionary
6 ATOMIC_AGGREGATE Well-known discretionary
7 AGGREGATOR Optional transitive
8 COMMUNITY Optional transitive
9 ORIGINATOR_ID Optional non-transitive
10 CLUSTER_LIST Optional non-transitive
- WEIGHT -

BGP Large Communities [RFC8092] が IANAによってcode 30を得た時に、code 30についてこのRFCと違う挙動を期待したルータはエラーとして対応した。

またエラーの場合でも、RFC7606に従う新しい実装は、不正な属性を含むルートをwithdrawnとして扱い、ルーティングテーブルから削除した。一方、RFC4271に従う古風なBGP実装は単に、BGPセッションを切断した。

BGPセッションを切断するのはやりすぎということでRFC7606でアップデートされた。

RFC7606より

This behavior is undesirable because a session reset impacts not only routes with the offending attribute but also other valid routes exchanged over the session. In the case of optional transitive attributes, the behavior is especially troublesome and may present a potential security vulnerability. This is because attributes may have been propagated without being checked by intermediate routers that don't recognize the attributes. In effect, the attributes may have been tunneled; when they reach a router that recognizes and checks the attributes, the session that is reset may not be associated with the router that is at fault. To make matters worse, in such cases, although the problematic attributes may have originated with a single update transmitted by a single BGP speaker, by the time they encounter a router that checks them they may have been replicated many times and thus may cause the reset of many peering sessions. Thus, the damage inflicted may be multiplied manyfold.

最近も似たような事件が起きた。2 June 2023にBGP attribute 28によってresetsが起きる問題が起きた。今回はalien attributesとしてあつかわれたことによる問題だったが、これは実際はRFC6790によって定義されたBGP Entropy Label Capabilityで、これはあまり良くないプロトコルということでRFC7447でdeprecatedとなった。（どっちみちこれはMPLSでネットワーク内部で使用されるべきものでインターネットに出るべきものではなかった）

 

deprecated valueをフィルターするのはよい対応。 Deprecation of BGP Path Attribute　Values 30, 31, 129, 241, 242, and 243 (RFC8093) を参考にできる。

 

IETF117 参加記　振り返り（感想編）

IETF

 

３回目の現地参加

ロンドン、横浜と続き今回３回目の現地参加。

ちょっとづつ顔見知りの人が増えてきて嬉しい。

人を知っていると会話の話に入り込んで、その輪にいた他の人と会話ができる。

やっぱり、始めてのIETFだった1回目の時にグーグルのインターンとしてグーグルとアップルの人たちと仲良くなりやすいかったのは凄い幸運だったと思うし、そっから３回目まで知ってる人を増やせたかなとおもう。

名前を知ってて話したいなって思ってて今回初めて話せた人だと、AlibabaのYunfei さん、Quinten de Coninck さん、Ben SchwaetzさんDNSOPのチェアたちとかかな。あと喋るのは初めてではないけど今回初めてMartin Thomsonさんとちゃんとした会話（議論）ができて嬉しかった。

逆に話したいなって思ったけど、タイミングが合わなくて話せなかった人はMatt Joras さんとかGeoff Hustonさん、Nishidaさん、かな。

（今回は学会のポスター発表が途中にあったため、火曜夜と水曜全日IETFを抜けることになってしまったので、そのぶん人と話す機会が減ってしまって結構もったいなかった。Social珍しくご飯が美味しかったって聞いてとても羨ましい）

サンフランシスコってことで勤務先から近かったおかげで来れたって言ってたAppleとかGoogleの人がいて、横浜で開催された時に日本人がたくさん参加できた時も思ったけどやっぱり開催地って大事。

 

次回は？

ロンドンに初参加した時は「次の横浜は日本開催だからいけます！！」って言ってて、

横浜のときは、「次行けるかわからないけど、頑張る」って言ってて、

今回は「See you at Prague」ってお別れの時に言ってた。プラハにも行かせていただけることに感謝。

 

その後は？

119はいけないことが決まってて、きっとその先も当分行くのが難しいと思う。

現地で人と会うことはできないけど、気になってるドラフト読んだり、メーリス追ったり、今のドラフトがRFCになれるように頑張りたい。

 

メンタル

ブログで書くようなことじゃないかもしれないが、今回月曜日に自分のメンタルは結構死んでた。

月曜日は会議としては初日だが、土日はハッカソンがあり、その前もちょっとNOC部屋にお邪魔させてもらってたので既に体の疲労があった。

その上、火曜日にv6opsで発表が控えてたため、緊張していたと思う。

正直なにが原因かわからないが、月曜日は自分の調子が良くなかったのを感じた。

 

IETFで発表させていただくのは、v6opsに関してはロンドンのときからさせていただいてるのに、なぜ今回はv6opsで発表を気にしていたか？

 

v6ops に出してるドラフトdraft-momoka-v6ops-ipv6-only-resolverをやる中で、自分の中でずっと、自分がドラフトを出したいがために世に必要とされていないドラフトを出して皆の時間を使ってる、という可能性にずっと悩ませれていた。

これは半分自覚していることで、draft-momoka-v6ops-ipv6-only-resolverはドキュメント化されるべきだと思っている面が自分の中にあるとともに、このドラフトはある意味自分がIETFに来るためのチケットでもあると自覚してる。IETFは皆が集まって標準化活動を行う場所でrunning codeが基本となっている。その場でdraftも実装もなく発言がなにもできない状態でいることは存在意義がわからないため自分にとっては辛い。IETFに来て意義ある時間を過ごせてるって思えるために今現在特に実装がない自分には自分のドラフトがあるというのは人と話す上で大事な話題だった。

IETFへ来るためのチケットのドラフトのために人の時間をとっていいのか、しょうもないことをしてる人だって思われていないか不安だった。（今も不安）

 

そうゆう不安な気持ちもあって気持ちが落ち着いていない時に、信頼できる人が周りにいたのは心強かった。Lucasさんにちょっと自分が短く言語化できる範囲で相談したし、土曜日の夜にEric Klyineさんにdraftのプロセスでストレス感じてないか確認されたし、DNSOPのチェアTimさんも自分はドラフトの著者を守るって言ってたし、v6ops のチェアのXiping さんも結構優しくしてくれている。

 

実際に火曜日発表してみるとLorenzoさんにいいコメントもらえたし、発表前にチェアのXiping さんに新しいドラフト出せばadopt draftになると思うよって言われて結構心が軽くなった。

 

帰ったらやること

備忘録用

  • HTTP wg listにWebSocket Happy Eyeballs についてコメントを書く
  • draft-momoka-v6ops-ipv6-only-resolver をアップデートする
  • rfc3901bis へコメントとプルリクを出す。
  • ドイツの人にメールをくる
  • Geoff Hustonにメール送る

 

Scotch bof

今回初めて本物のScotch bofに参加できた気がする。とくに決まった主催者がいるわけではなく木曜夜までに人伝にスイートルームを借りてて主催したいって人の部屋を嗅ぎ回って、夜に行くって感じ。

（ロンドンの時もScotch bofに参加したけど、それは会場のHackathon部屋が施錠されてなくてそこにみんな集まっていたから部屋が広くてちょっと違う雰囲気だった。）

二つ部屋があるらしいって聞いたけど片方だけにいた。入った時は20人行かないぐらいだったのかな。結構いた。たくさん出たり入ったりしたとおもから持っといたと思う。たくさんウィスキーが置いてあった。（次プラハ行く時は自分も日本からなにか持っていきたいけど、ウィスキー飲まないから選べないんだよな。ウィスキーに合う日本のおやつとか探そうかな）

 

San Francisco

人生で一番寒い夏だった。

（中学生の時にオーストラリアに行ったことがあったけどその時もこんなに寒いって思わなかったはず）

気温を確認せずにスーツケースにTシャツだけ持って行ったため上着を買う必要があった。

かった上着も春もので服は最低限の暖かさだし、体は日本の35度の灼熱に慣れてたから、夜外を歩く時は震えてた。でも半袖で平気そうな人もいて信じられなかった。

 

ホームレスがたくさんいた。

ホテルと会場ホテルの往復でもよくホームレスの人をみた。

 

あまり1人で散歩するのが好きな人間ではないので、お菓子と上着を買う時しか1人で外を歩かなかった。正直ご飯を探す以外で街を探検しなかった。

最終日にお土産用にホテルのすぐ近くのGoogleMapで見つけた小さなスーパーに行ったが、治安が悪いところのちょっと手前のストリートだった。その時点で道にテントがあり道も臭く、怖かった。スーパーの店員さんにあっち（ホテルと逆方向）はもっとテントが歩道にあって歩けないよって言われた。

明るい時にちょっと治安が悪いところを歩いただけで怖いって思ったから絶対に夜に治安が悪い部分いけないなって思った。

 

またSFに来たいとは思わなかった。少なくとも夏には来ない。

 

過去記事リンク

今回日記がてら書いたやつ。

momoka0122y.hatenablog.com

momoka0122y.hatenablog.com

momoka0122y.hatenablog.com

momoka0122y.hatenablog.com

 

過去書いたやつ

 

momoka0122y.hatenablog.com

momoka0122y.hatenablog.com

momoka0122y.hatenablog.com

 

IETF117　4日目

IETF

WEBTRANS 

WebTransportがFirefoxに入ったらしい。

 

 IRTF Open Meeting　Model-Based Insights on the Performance, Fairness, and Stability of BBR

BBRの研究。

年表わかりやすい。ちょうど火曜日のccwgでgoogleからBBRv3の話が出たところ。

 

HTTP (httpbis)

notes:

HTTP Working Group Minutes - IETF 117 - HedgeDoc

話し終えてなくてメモれてないけど他以下の三つの話もあった。

Compression Dictionary Transport - Patrick Meenan 
HTTP Availability Hints - Mark Nottingham
HTTP Cache Groups / An HTTP Cache Invalidation API - Mark Nottingham 

Secondary Certificate Authentication of HTTP servers

スライド

https://datatracker.ietf.org/meeting/117/materials/slides-117-httpbis-secondary-certificate-authentication-of-http-servers

Apple からの発表　（akamai, M. Bishop先生が共著者）

使われ方。

今回新しく出てきた、proxyとして使う方法。

前回これを標準化しようとした時複雑になりすぎて無理だったから、unprompted server authentication にのみ対応。

考えないといけないこと

- SETTINGS を使う必要はあるか、

- client prompt certificates は？

　複雑だし、プライバシーの問題が考えられるので今回が考えない。（例えば、サーバが候補を提示してクライアントが選ぶ形式だと、サーバに悪意があった場合クライアントがどのドメインに興味があるかバレてしまう。）

 

adoptionするかどうか？

20yes, 4no

akamai, Cloudflare からやりたいという意見がでた。

クライアント（発表者以外のブラウザはfirefox, chrome）側からはそんなに意見がなかった。

Martin Thomson (MT): Didn’t go either way. Want to spend more time clarifying what the use cases are, more discussion of that - current discussion was more in details.

 

David Schinazi (chat) : I'm in another session so I can't come to the mic but I'm supportive of this work

 

Martin Thomson(chat): I would infer from this that Apple wants to do the hybrid proxy deployment (iCloud Private Relay has forward proxies that are also reverse proxies...)

（あまりまだ理解できてないけど、すごいサーバ側には魅力的だけど、ブラウザ側的には他の機能と比べたら優先度低そうな気がした。）

クライアントから認証する話は、今回しないけど、それってそもそもunprompted auth じゃないって話を人がしてた。

Request-OTR Header

Braveからの提案。

シークレットブラウザモードじゃない時に、サイト側がブラウザに履歴に載せないでって教える機能。

したの意見に自分は結構同意した。

Dennis Jackson (DJ): Interesting. Concern is that it is not as effective as Private Browsing, and users could think this is actually secure, while local history could save it. Any way to avoid telling user about this, avoid confusion? Otherwise have complicated user education issue. Concerned that this is pitched as privacy measure, that’s not effective and might be actively harmful.

 

MT: Privacy CG chair at W3C - can probably take this.

あまり、W3Cがやってることはわからないけど、プロトコル面以前に機能の議論が必要そうだからW3Cが始めた方がIETF HTTPよりいいのかもしれない。

 

 

 

 

 

よるはscotch bof へいってきた。いろいろ人が出きりして20人行かないぐらいいたのかな。ほぼほぼこの一週間で仲良くあった人たちと話してた。