0.0.0.0/8のIPアドレスなどを利用可能にする提案仕様

IPv4アドレスの枯渇すると言われ続けております。

「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。

実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。

• 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240)
• 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0)
• 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127)
• IPアドレスのホスト部が0のものを利用可能にする提案(draft-schoen-intarea-unicast-lowest-address)

単に提案するだけでなく、歴史的経緯の説明が書かれています。また、問題なく利用できるかの調査も行っており、例えば各種OSやネットワーク機器の実装の調査、クラウドサービスなどで内部的利用の調査も行っています。

IETF 112で発表があるようなので簡単に予習をしておく。

発表スライド(PDF)もあわせて参照ください。

なお、IETFへの提案は誰でも行うことが出来き、あくまで提案であるということに注意してください。ですので、すぐにIPアドレスの運用が変わるということはなく、オープンな場で議論が進められます。（ご意見のお持ちの方はもちろん参加できます）

240.0.0.0/4

240.0.0.0/4は、Class Eや実験用アドレスレンジとして予約されているIPアドレスです。このレンジをユニキャストアドレスとして使用できるようにします。

このIPアドレスを、Linux, Android, macOS, iOS といったOSではユニキャストアドレスとして使用できるようです。ただし、Windowsではブロックされると述べています。

GCPのドキュメント(URL)では、VPCのサブネットとしてこのレンジが利用できると書かれています。

0.0.0.0/8

0.0.0.0/8は、仕様上は、RFC 792で自動構成用に予約されていました。これはRFC 1122によって廃止され、今日まで何も予約されていません。DHCPでのみ0.0.0.0が利用されています。このレンジをユニキャストアドレスとして使用できるようにします。

ユニキャストアドレスとして使うことに関して、提案仕様の中でLinuxについては『この文書で指定されている動作は、2019年7月にリリースされたバージョン5.2以降のLinuxカーネルによって実装されています。』と書かれています。

127.1.0.0 ~ 127.255.255.255

IPv6にループバックアドレスは一つしかありませんが、IPv4では 16,777,216個も確保されています。127.0.0.0/16をループバックアドレス用に利用し、127.1.0.0 ~ 127.255.255.255をユニキャストアドレスとして使用できるようにします。

ユニキャストアドレスとして使うことに関して、提案仕様の中で『LinuxおよびFreeBSDカーネルへの小さなパッチが必要』と述べています。

IPアドレスのホスト部が0のもの

例えば、93.184.216.0/24サブネットの中の93.184.216.0をユニキャストアドレスとして使用できるようにします。このアドレスは1980年代の古い実装との互換性のために使用されてこなかったと述べています。

現在では、LinuxやFreeBSDではデフォルトでユニキャストアドレスとして扱うようです。

おわりに

冒頭にも書きましたが、IETFへの提案は誰でも行うことが出来き、これは議論の始まりに過ぎません。これによりすぐにIPアドレスの運用が変わるということはないかと思います。

一方で、実装やインターネット通信上で多くの懸念を持たれる方もいると思います。提案者はコメントを募集されておりますので、コンタクトを取られると良いと思います。議論は IETF int-area メーリングリストで行われます (URL)。

匿名かつ検証可能なPrivate Access Tokensの提案仕様 (プライベートアクセストークン)

「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。

この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。

昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、

そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。

それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access Tokens」です。

IETF 112のSec Dispatch WGのセッションで発表(Agenda)があるようですが、簡単に予習しておきます。(追記: 発表資料スライド)

なお、RSAブラインド署名やHPKEなど、使われている暗号処理はまではまだ理解できてないので概要だけ。

仕様の内容

この仕様では、大きく分けて２つのことが書かれています。

• Private Access Tokensの発行する手順 (Issuance Flow)
• Private Access Tokensを使用する手順 (Challenge/Response Flow)

また、各手順に置いて、登場人物がどのようなやり取りをするのかが定義されてます。

登場人物

• Client: IssuerにPrivate Access Tokensをリクエストし取得する。Originのサービスにアクセスするために、Private Access Tokensをオリジンに提示する。
• Mediator: IPアドレスやアカウント名などの情報をも使用してClientを認証する。ClientをIssuerに対して匿名化し、匿名化されたClientとIssuerのやりとりを中継する。
• Issuer: Originに代わって匿名化されたClientにPrivate Access Tokensを発行する。OriginをMediatorに対し匿名化し、Originのポリシーを適用する。
• Origin: ClientをチャレンジでIssuerにリダイレクトする。そして、クライアントからのレスポンスとしてPrivate Access Tokensを受け取る。Clientにコンテンツやサービスを提供する。

IssuerはOriginによって選択されますが、MediatorはClientによって選択されます。

IssuerはOriginがClientに課したいポリシーを知っており、Originに代わりそれらを課します（ポリシーは、クライアントごとに10アクセスに制限すると言った例）。なお、IssuerへアクセスではClientの情報は匿名化されているため、本当のユーザはわかりません。

各登場人物は処理が必要な情報だけしか知りえません。共謀しないとい前提で、各登場人物がどのような情報を知りえるかは仕様の方を御覧ください。

大雑把な流れ

大雑把な流れは以下のとおりです。赤字がChallenge/Response Flowになります。

• ClientがOriginにアクセスする
• Originは、Challenge/Response Flowの一環としてOriginからIssuerにリダイレクトを行う。このとき、WWW-AuthenticateヘッダでTokenChallenge及び、Issuance Flowに必要な情報をClientに通知します
• Clientは、TokenChallengeをブラインド処理し、Issuer固有の鍵で暗号化した上で、Mediatorを介してIssuerにPrivate Access Tokensを要求します。
• Issuerは、復号を行い、各種検証を行った後、ポリシーの適応とPrivate Access Tokensの発行を行います。Mediatorを介してClientに渡されます。
• ClientはChallenge/Response Flowの一環として、ResponseをOriginに送信します。

感想

Issuance Flowの細かいところ難しい...

クレデンシャルを安全に共有する「Secure Credential Transfer」の仕様

AppleとGoogle方らによって「Secure Credential Transfer」という提案仕様が、IETFのDispatch WGに提出されています。

この仕様は、イントロダクションにも書かれている通り、iOSやAndroidといったプラットフォームの異なるデバイス間でクレデンシャルを共有する方法を定めています。

実際にそういったデバイスを作ってる方々からこのような提案が出てくるというのは興味深いところです。

Secure Credential Transferの概要

この「Secure Credential Transfer」では、リレーサーバというWebアプリケーションを導入し、SenderからReceiverにクレデンシャルを共有します。

共有方法には2つの手順があり

• ステートレス: 単一のクレデンシャルのみ送信できる
• ステートフル: 複数のデータを送信できる。ただし手順が長い。

どちらの手順でも、SenderとReceiverは、リレーサーバ上にメールボックスを作成し操作します。メールボックスは仕様上の用語であり、Eメールは関係なく、WebのAPIを介し読み書きを行います。メールボックはそれぞれユニークなURLをもちます (例: https://relay.example/m/1234567890)。

SenderとReceiverが、リレーサーバとやりとりする、ときに使用するAPIに関してもこの仕様で定義されます。

また仕様上は、Provisioning Partnersという用語が出てきます。これは、デバイス上でProvisioning Infoを取り扱う主体(エンティティ)を指す用語です。

ステートレス ワークフロー

簡単なステートレスのワークフローで簡単な流れを紹介します。

• Senderは、Secretを用いてクレデンシャル情報をProvisioning Infoとして暗号化します。
• Senderは、リレーサーバのCreateMailbox APIを利用して、メールボックスを作成します
• リレーサーバは、作成したメールボックスのURLを返します
• Senderは、得られたメールボックスのURLとSecretを直接Receiverに送ります。仕様上では例として、次のものが上げられています。SMS、電子メール、iMessage。
• Receiverは、URLとSecretの療法を用いて、Relayサーバーから暗号化されたProvisioning Infoを受け取ります。
• Receiverはクレデンシャルを取り出した後、該当のメールボックスを削除します

なお、このやり取りの中で、メールボックスは特定のSenderとReceiverに紐付けられます。SenderとReceiverは自身のDevice Claim(トークン)を登録して、それを用いてリレーサーバのAPIを叩きます。そのため、Device Claimが登録された後は、ほかのデバイスはそのメールボックスを利用できません。

なおSenderからReceiverへSecretを送る際、誤った相手と共有してしまうと問題になります。その旨Security Considerationsにも記載されています。

こんご

この仕様については、Dispatch WGのメーリングリストに投稿されています。来月行われるIETF 112で、どのように標準化を進めるか議論されることでしょう。

DNS HTTPSレコードを使用したWebSocketサポートの通知

以前紹介した通り、HTTP/3やECHに対応していることをDNSで通知するためのHTTPSレコードというものがあります。
asnokaze.hatenablog.com

このHTTPSレコードで、WebSocketの対応についても通知できるようにする「Advertising WebSocket support in the HTTPS resource record」という提案仕様がMozillaの方より提出されています。

モチベーション

これは、特にHTTP/2やHTTP/3でWebSocketを使う際にメリットがあります。

それぞれの動作については以前書いたとおりです

• 「ChromeがWebSockets over HTTP/2に対応したので試す (RFC8441) - ASnoKaze blog」
• 「Bootstrapping WebSockets with HTTP/3 の仕様 - ASnoKaze blog」

既存のWebSocket over HTTP/2とWebSocket over HTTP/3では、拡張CONNECTメソッドを用いてストリームをWebSocket通信用に切り替えます。仕様上、この拡張CONNECTメソッドをクライアントが使うためには、サーバがこの拡張をサポートしていることを知る必要があります。

サーバが拡張CONNECTメソッド対応していることは、HTTP/2, HTTP/3コネクションが確立した後にサーバから送られてくるSETTINGSフレームで知ることが出来ます。つまり、クライアントは、このSETTINGSフレームの受信を待ってCONNECTメソッドのリクエストを送ることになります。

「Advertising WebSocket support in the HTTPS resource record」では、HTTPSレコードにWebSocket (拡張CONNECTメソッド)への対応が記述されるため、SETTINGSフレームの受信を待つ必要がありません。

HTTPSレコードの拡張

HTTPSレコードの仕様で定義されるSvcParamKeyとしてextended-connectキーを新しく定義します。この、extended-connectがある場合はalpnとしてh2かh3を指定する必要があります

おそらくこんな感じ

   simple.example. 7200 IN HTTPS 1 . alpn=h3 extended-connect ...

おまけ

似たようなモチベーションで検討されている仕様があります。

TLS ALPSという仕組みがChromeでは実装されています。これも、TLSハンドシェイク中にHTTPレイヤのSETTINGSを送信可能にします。
asnokaze.hatenablog.com

HTTP/2の改定版仕様(RFC9113)の変更点について

2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。

作業中のドキュメントは「http2bis」として公開されている。

現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。

HTTPセマンティクス仕様を参照

もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。

それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。

セマンティクス側の変更点について以前書いた記事を参照ください。

asnokaze.hatenablog.com

TLS 1.3 への対応

もともとのHTTP/2の仕様は、TLS 1.3が出る前に標準化されました。その後、RFC8740「Using TLS 1.3 with HTTP/2」としてHTTP/2においてTLS1.3を使う場合の仕様が記述されています。

今回の改訂版は、RFC8740を取り込みつつ、TLS 1.3の使い方について言及しています

• RFC8740に則り、post-handshake authenticationの禁止される
• NewSessionTicketおよびKeyUpdateはHTTP/2に影響がないので、そのまま使用できる
• RFC8470 に準じていれば、TLS 1.3 の 0-RTT Early DataでHTTPリクエストを送信出来る

RFC7540で定義される優先度制御の廃止

もともとHTTP/2で定義された依存関係を指定する優先度制御方式は、複雑すぎるということで廃止されました。以前紹介した、新しいHTTP優先度制御方式の使用が推奨されます。
asnokaze.hatenablog.com

改訂版では、具体的な優先度制御に関する記述が削除されました。ただし、既存のHTTP/2実装と互換性を維持するために、PRIORITYフレームやHEADERSフレームのフォーマットは変更はありません。既存のPRIORITYフレームを受信した場合は単純に破棄されます。

アップグレードを廃止

もともとの仕様では、HTTP/1.1でつないでから、その通信をHTTP/2にアップグレードする手順が定義されていました。ほぼ使われていないため、この方式は廃止されました。

フィールドのバリデーションを厳密に行う

ヘッダなどのフィールドにおいて、どのような文字が許容されるか、検証項目がより厳密になりました。

HTTP/2からHTTP/1.1に通信を中継するリバースプロキシの実装で、いくつかの脆弱性が見つかったため、より厳密に言及されるようになりました。

基本的には実装上の脆弱性ですが、具体的な攻撃手法は、「HTTP/2: The Sequel is Always Worse | PortSwigger Research」などを参照ください。

Experimental Useを開放

Experimental Useとして予約されていた拡張フレームタイプ値・SETTINGSパラメータ値を開放

Hostヘッダと:authority疑似ヘッダが一致すること

Hostヘッダと:authority疑似ヘッダが必ず一致することが必須となりました。

これも、HTTP/2からHTTP/1.1にプロキシする場合に、曖昧な部分があったため、厳密化されました

HTTP Datagram PING の拡張仕様についてのメモ

「HTTP Datagram PING」という提案仕様をGoogleのBenjamin Schwartz氏がIETFに提出している。

これは、HTTP/3でのDATAGRAMフレームにおいて、PINGを送れるようにするものである。HTTP/3におけるDATAGRAMフレームの利用については以前紹介したとおりである。
asnokaze.hatenablog.com

目的

WebTransportやMASQUEでは、DATAGRAMフレームはプロキシを超えてEnd-to-Endでのやりとりに利用できるように設計されています。このHTTP Datagram PINGを使う目的は主に次のとおりである

• End-to-Endにかけてコネクションが維持されており、通信が出来ることを確認する
• End-to-Endで通信のレイテンシを確認する
• End-to-EndでPath MTU Discoveryを行う

特に、3つめにあげたのが、この提案の主題でもあります。

もともとMASQUE WGでは、HTTPプロキシを超えたPath MTU Discoveryについてどのように行うか議論がありました。例えば、CONNECT-IPでは、MASQUE Proxy先のMTUを考慮してクライアントはDATAGRAMフレームを送信しなければなりません。その問題に対して一つの提案として出されたのがこの仕様です。

具体的には、トランスポートレイヤでのPath MTU Discoveryを説明した「RFC8899」で定義されている通り、DPLPMTUD Probeパケットの送信に使用できます。

なお、CONNECT-IPは以前紹介したとおりです。
asnokaze.hatenablog.com

（この仕様では、MASQUE Proxyを超えてはPath MTU Discovery出来ない？ちょっと、そこを理解できてない。）

HTTP Datagram PING

具体的なHTTP Datagram PINGの中身を確認します。

最新版の「Using Datagrams with HTTP」では、DATAGRAMフーレムに拡張性を持たせている。HTTP Datagram Format Typeとして、新しいFormat Typeを定義できる。

「HTTP Datagram PING」では、新しいFormat TypeとしてPING Datagram Formatを定義している。

QUICのDATAGRAMフレーム及び、REGISTER_DATAGRAM_CONTEXT Capsule Formatも含め記述すると次のとおりである。

PING Datagram Formatは、シーケンス番号と任意のOpaqueデータを含みます。

PINGフレームを受け取ったエンドポイントは、同様にPINGフレームを応答する必要があります。

大体の位置情報を示すSec-CH-Geohashヘッダ

Private Relayをはじめ、Proxyを通してクライアントのIPアドレスをサーバに対して隠す技術が登場しています。

ところで、Webサービスはクライアントの位置情報によって出力する情報を変えたり、最適化を行う場合があります。JavaScriptのGeolocation APIから取得することもあるでしょうが、APIアクセスなどJavaScriptが利用できない場合もあるでしょう。その場合、IPアドレスから位置情報を類推する手段(GeoIPなど)があります。

IPアドレスから位置情報をある程度推測する手法は、IPアドレスが隠されると機能しなくなります。

Private Relayではユーザが望む場合は、Webサーバに対して大体の位置情報を提供するという観点について、IETF 111の発表で触れています。

(https://datatracker.ietf.org/meeting/111/materials/slides-111-pearg-private-relay-00)

以下の２つが上げられています

• egress proxyを選択
• Geohashを Client Hint で提供する

The Geohash HTTP Client Hint

大体の一を示すGeohash をヘッダでサーバに提出する方法「The Geohash HTTP Client Hint」の仕様が、Appleの方よりIETFに提出されています。（なお、この方法が、実際に使用されているかは定かではありません。）

Geohashは任意の精度で緯度経度を示す方法です。近い文字列は近い場所を示します。また、末尾から文字を削るほど精度が低くなります。
ja.wikipedia.org

HTTP Client Hintの仕組みに則り、Webサーバがサポートしている場合、クライアントが望めばSec-CH-GeohashヘッダでGeohashを提出します。

動作例

• 1. まずクライアントはWebサーバにHTTPリクエストを送る
• 2. サーバは、HTTPレスポンスヘッダのAccept-CHでSec-CH-Geohashをサポートしていることを伝える

  Accept-CH: Sec-CH-Geohash

• 3. クライアントは、次のHTTPリクエストからSec-CH-Geohashでジオハッシュを送信する

Sec-CH-Geohash: "u4pruydqqvj"

u4pruydqqvjは、緯度経度(57.64911,10.40744)を示します。