Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ietf97 ソウル報告

620 views

Published on

IETF97 参加報告
- httpbis
- QUIC
- etc

Published in: Technology
  • Login to see the comments

Ietf97 ソウル報告

  1. 1. IETF97 ソウル報告 @flano_yuki
  2. 2. お前だれよ - @flano_yuki - しがないインフラエンジニア - IETF94@Yokohama 以来2度目 - アドベントカレンダー頑張っていきましょう...
  3. 3. IETF97 ソウル - 日付: November 13-18, 2016 - 場所: コンラッドソウル 汝矣島 - 人数:996人 (jp:約60) - 122 meeting (wg, irtf, bof) - 資料(URL) - 動画(URL) -
  4. 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のメンテナンス
  5. 5. 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 - ...
  6. 6. 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
  7. 7. httpbis active work
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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フレームをすすめる
  12. 12. httpbis Potential work
  13. 13. An HTTP Status Code for Indicating Hints - draft-kazuho-early-hints-status-code-00 - preloadなどのレスポンスヘッダを先に送るための、103ステータスコードの定義 - h2o, nghttp2で実装済み - interoperabilityの懸念あり
  14. 14. 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.
  15. 15. 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
  16. 16. Cache-Control: immutable - draft-mcmanus-immutable-00 (発表資料URL) - cache-controlの拡張 - いわゆる、ブラウザのリロード(F5)でもキャッシュを使用するようにする - ex「 Cache-Control: immutable 」 - Strong hum for adoption, none against.
  17. 17. 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
  18. 18. 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.
  19. 19. 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
  20. 20. 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
  21. 21. Charter (2/3) 5つのフォーカス事項 - core transport work - security - mappings between specific application protocols - multipath capabilities - Applicability and Manageability Statement
  22. 22. 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
  23. 23. 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 ■ それぞれ分離する ○ プラガブル ○ 輻輳制御の要件を記述すべきか ?
  24. 24. 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が提出される)
  25. 25. 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
  26. 26. その他
  27. 27. その他 (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のコメントを求めては?」
  28. 28. その他 (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の測定結果など ○

×