IETF97 参加報告 - httpbis - QUIC - etc

1. IETF97 ソウル報告
@flano_yuki

2. お前だれよ
- @flano_yuki
- しがないインフラエンジニア
- IETF94@Yokohama 以来2度目
- アドベントカレンダー頑張っていきましょう...

3. IETF97 ソウル
- 日付: November 13-18, 2016
- 場所: コンラッドソウル 汝矣島
- 人数:996人 (jp:約60)
- 122 meeting (wg, irtf, bof)
- 資料(URL)
- 動画(URL)
-

4. IETF97 ソウル トピック
- httpbis wg: HTTP1.1 or 2のメンテンナス・拡張
- QUIC wg: QUICの標準化wg
- その他
- maprg: 測定・解析 RG
- sunset4: v4廃止 wg
- dnsoverhttp: dns over http BarBoF
- tcpm / tsv : Transportのメンテナンス

6. 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
- ...

7. 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

8. httpbis active work

9. 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

10. 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

11. 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

12. 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フレームをすすめる

13. httpbis Potential work

14. An HTTP Status Code for Indicating Hints
- draft-kazuho-early-hints-status-code-00
- preloadなどのレスポンスヘッダを先に送るための、103ステータスコードの定義
- h2o, nghttp2で実装済み
- interoperabilityの懸念あり

15. 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.

16. 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

17. Cache-Control: immutable
- draft-mcmanus-immutable-00 (発表資料URL)
- cache-controlの拡張
- いわゆる、ブラウザのリロード(F5)でもキャッシュを使用するようにする
- ex「 Cache-Control: immutable 」
- Strong hum for adoption, none against.

18. 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.1
Range: bytes=0-
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-99408383/*
Content-Length: 99398384

19. 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.

21. 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

22. 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

23. Charter (2/3)
5つのフォーカス事項
- core transport work
- security
- mappings between specific application protocols
- multipath capabilities
- Applicability and Manageability Statement

24. 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

25. 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
■ それぞれ分離する
○ プラガブル
○ 輻輳制御の要件を記述すべきか ?

26. 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が提出される)

27. 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

28. その他

30. その他 (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のコメントを求めては？」

31. その他 (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の測定結果など
○