IETF97 ソウル報告@flano_yuki

お前だれよ

- @flano_yuki- しがないインフラエンジニア

- IETF94@Yokohama 以来2度目

- アドベントカレンダー頑張っていきましょう...

IETF97 ソウル

- 日付: November 13-18, 2016- 場所: コンラッドソウル 汝矣島

- 人数:996人 (jp:約60)- 122 meeting (wg, irtf, bof)- 資料(URL)- 動画(URL)-

IETF97 ソウル トピック

- httpbis wg: HTTP1.1 or 2のメンテンナス・拡張

- QUIC wg: QUICの標準化wg

- その他

- maprg: 測定・解析 RG

- sunset4: v4廃止 wg

- dnsoverhttp: dns over http BarBoF

- tcpm / tsv : Transportのメンテナンス

httpbis wg (1/2)

- Co-Chair: Patrick McManus - minuets (URL)- 2セッション開催

- Active Drafts- draft-ietf-httpbis-jfv and draft-kamp-httpbis-structure- draft-ietf-httpbis-origin-frame- draft-ietf-httpbis-http2-encryption

- Experiences with Alt-Svc for HTTP Opportunistic Security- ...

httpbis wg (2/2)- Potential and Related Work

- Early Hints- Expect-CT Certificate Transparency Response Header- Cache-Control: immutable- SDCH / Compression Dictionaries for HTTP/2- HTTP bytes-live Range Unit for Live Content- Messaging/Websockets for H2

httpbis active work

draft-ietf-httpbis-jfv- A JSON Encoding for HTTP Header Field Values について、Julianから発表

- HTTPヘッダ値をJSON形式の表現を定義し、構造のあるヘッダのパースを容易にする

- Concerns about data model (number formats) and potential interop issues (non-unique member names)

- Specs in W3C have started using the syntax:- https://www.w3.org/TR/2016/WD-reporting-1-20160407/#header- https://www.w3.org/TR/clear-site-data/#header- https://wicg.github.io/feature-policy/#feature-policy-http-header-field

draft-kamp-httpbis-structure- HTTP header common structure PHKから発表

- Common Structureという、HTTPヘッダの新しいデータ構造とデータモデルを定義

- Hum: The feeling in the room was that we should abandon the JFV draft and adopt the structure draft in its place

value = identifier / number / ascii_string / unicode_string / blob / timestamp / common-structure

draft-ietf-httpbis-http2-encryption - Opportunistic Security for HTTP- http:// のときでも暗号化通信を行う(相手を認証しない、日和見暗号)- オリジンのハンドリングへの懸念

- Cloudflareでの実証実験の報告

- Encryption Week: September 2016- TLS 1.3: improve security for HTTPS sites - Automatic HTTPS rewrites (enable HTTPS for sites with fixable

mixed content)- Opportunistic Encryption with valid certificates by default

- 25-75k rps encrypted with opportunistic encryption

draft-ietf-httpbis-origin-frame- The ORIGIN HTTP/2 Frame- コネクションの再利用できるオリジンを通知するフレーム

- (OEでも議論が出たが)、do_not_allow_mixed_originsとallow_mixed_schemeを行う

ために、新しくSETTINGSを定義するか、ORIGINフレームを変更するか

- ML (URL) で報告されているとおり、新しいSETTINGSのドキュメントを待ったから

ORIGINフレームをすすめる

httpbis Potential work

An HTTP Status Code for Indicating Hints- draft-kazuho-early-hints-status-code-00- preloadなどのレスポンスヘッダを先に送るための、103ステータスコードの定義

- h2o, nghttp2で実装済み

- interoperabilityの懸念あり

Expect-CT Certificate Transparency Response Header- draft-stark-expect-ct-00- CT(Certificate Transparency)が使用されていることを要求するHTTPヘッダー

- chromeではprelaodな設定が有効になっている

- 今後chromeでは、CA/Bで報告済みの通りCTが必須にしていく

- 例「expect-ct: enforce;max-age=3600;report-uri=https://example.com/report-uri 」- Hum if this is a reasonable are for the WG to work in? Strong hum for, some

against.

SDCH / Compression Dictionaries for HTTP/2- コンテンツ圧縮の提案(content-encoding)- SDCH (発表資料URL)

- 静的的辞書

- chromeで実装済み、unship?

- Compression Dictionaries for HTTP/2 (発表資料URL)- Cloudflareの提案、実証済み

- H2でCSS, JSの結合を行わない、コンテンツ圧縮率が下がってる

- 新しいフレームを定義し、最初にデータの頭を未圧縮で送信し辞書登録し、各ストリームで使用す

る

- 通常のDeflate(zlib compression level 8))より最大1.50倍、平均で1.10倍縮小できたとしている

- セキュリティ issue

Cache-Control: immutable- draft-mcmanus-immutable-00 (発表資料URL)- cache-controlの拡張

- いわゆる、ブラウザのリロード(F5)でもキャッシュを使用するようにする- ex「 Cache-Control: immutable 」

- Strong hum for adoption, none against.

HTTP Random Access and Live Resources- draft-pratt-httpbis-rand-access-live-00 (発表資料URL)- ライブコンテンツといった長さが未定のものに対する、HTTP Rangeリクエスト

- RFC 7233において、”206 Partial Content” は長さ不明を示せない

- Content-Range で *を使用し、長さ不明を示す

HEAD /my_resource HTTP/1.1Range: bytes=0-

HTTP/1.1 206 Partial Content Content-Range: bytes 0-99408383/* Content-Length: 99398384

WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

- draft-yoshino-wish-01 (発表資料URL)- HTTP上で双方向メッセージングをサポートするWiSHフレームの定義

- WiSHフレーミングはWebSocketと互換性があるように設計されている

- QUICといった、進化がまだあるが、双方向通信・Websocktはどうしていくか

- Chair:What is the future of WebSockets? HTTPBis is not the right place for

this. This should be discussed in BarBof or go on to Dispatch WG.

QUIC wg- Co-Chair:

- Lars Eggert - Mark Nottingham

- 前回(ietf96)で WG formingのbofが行われ、今回はじめてのWG meeting- 200人くらい入ってた。大盛況。

- minuets (URL)- topinc

- Charter Overview- 4 drafts & adoption- QUIC Endian

Charter (1/3)Key goals for QUIC are:

- Minimizing connection establishment and overall transport latency for applications, starting with HTTP/2;

- Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default

Charter (2/3)5つのフォーカス事項

- core transport work- security- mappings between specific application protocols- multipath capabilities- Applicability and Manageability Statement

Charter (3/3)○ May 2019 - Multipath extension document to IESG○ Nov 2019 - QUIC Applicability and Manageability Statement to IESG○ Nov 2018 - HTTP/2 mapping document to IESG○ Mar 2018 - TLS 1.3 Mapping document to IESG○ Mar 2018 - Loss detection and Congestion Control document to IESG○ Mar 2018 - Core Protocol document to IESG○ Nov 2017 - Working group adoption of Multipath extension document○ Feb 2017 - Working group adoption of QUIC Applicability and Manageability Statement○ Feb 2017 - Working group adoption of HTTP/2 mapping document○ Feb 2017 - Working group adoption of TLS 1.3 mapping document○ Feb 2017 - Working group adoption of Loss detection and Congestion Control document○ Feb 2017 - Working group adoption of Core Protocol document

drafts (1/2)4つのindividual-draftの紹介と、adoption のhumが実施され、

全て wg itemにadoptionされた https://github.com/quicwg/base-drafts

● draft-hamilton-quic-transport-protocol ○ core spec

■ 多重化、フレーミング、 erro...etc...etcr○ version numer, endian, packet number vs Sequence number

● draft-iyengar-quic-loss-recovery ○ loss detection と loss recoveryのalgorithm

■ それぞれ分離する

○ プラガブル

○ 輻輳制御の要件を記述すべきか ?

drafts (2/2)● draft-thomson-quic-tls

○ handshake (using tls 1.3), encryption, key phase○ TLS部分をブラックボックスとして使いたい ○ Discussion what attacks are possible against this proposal.

● draft-shade-quic-http2-mapping ○ h2のマッピング

■ 各ストリームの使い方 stream 1(crypt), stream3の使い方

■ alt-svc○ 1つのQUICコネクション上で、1つのアプリケーションデータしか転送できないのか？

○ A Fork in the Road■ HTTP/2 over QUIC ■ Fresh HTTP Mapping over QUIC: QPACK (会期中に i-dが提出される )

topic● QUIC Identifiers (発表資料URL)

○ transport layerの識別子(32bit)とALPNの識別子がある

■ それぞれ直交すべき

○ ALPNの識別子を ”quic-<draft version>”● Endian Issues (発表資料URL)

○ Hum: A very clear hum for big endian, only a little support for little endian● Flow-state signaling and QUIC (発表資料URL)

○ https://tools.ietf.org/html/draft-trammell-plus-statefulness-00

その他

その他 (1/2)● Measurement and Analysis for Protocols (maprg)

○ H2 performance analysis in the real world■ Real User Monitoring■ H2 is not always a straight win■ Losses hurt H2 (only 1 TCP connection)■ Depends on the site characteristics

● Sunsetting IPv4 (sunset4)

○ Let 'localhost' be localhost (draft-west-let-localhost-be-localhost)■ secure contextで “localhost” をsecure contextにしたいというモチベーション

● RFCでは現状 “localhost”をloop back addressにするのは SHOULD■ SHOULDの部分をMUSTにする提案仕様

■ 「DSN WGのコメントを求めては？」

その他 (2/2)● dnsoverhttp

○ barBoF (ただし会議室 ) 70 人くらい参加

○ 確かもともと dnsop で議論されていた ■ dnsがブロックされたときに 80/443 を使用する

■ 「DNS wire-format over HTTP」「DNS Queries over HTTPS」○ http/2でコネクションをまとめたり、 pushしたい等...○ privacy, cache/ttl...

● tcpm / tsv○ Linux netdev update

■ netdev というカーネルデベロッパーのカンファレンスでの topic■ Bottleneck Bandwidth and RTT(BBR)の話

■ FacebookがkernelレイヤでTLS実装してたりする ...○ RACK: a time-based fast loss recovery

■ RACKの測定結果など

○