IETF93 Prague報告Web関連+QUIC

https://lepidum.co.jp/ Copyright © 2004-2015 Lepidum Co. Ltd. All rights reserved.
IETF93 Prague
Web関連+QUICレポート
株式会社レピダム
前田薫 (@mad_p)
IETF93報告会 2015/08/27
IETF93報告会2015/08/27

Copyright © 2004-2015 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Agenda
 WG
 appsawg, httpbis,
rtcweb, webpush, netvc
 oauth, tokbind
 QUIC Barbof
 IETF93
 Prague, CZ
 2015/07/19-24
IETF93報告会2015/08/27

自己紹介
 名前
 前田薫 @mad_p
 所属
 株式会社レピダム
シニアプログラマ
マネージャ
 コミュニティー活動
 Lightweight Language
 Identity Conference
 http2study
 業務領域
 認証・認可、デジタル
アイデンティティー、
プライバシー
 標準化支援
 ソフトウェアセキュリ
ティー、脆弱性
 IETFとの関わり
 IETF89 Londonより
 ART, SECエリア中心
IETF93報告会2015/08/27

 概要
 APPSエリアのエリアWG
 月曜朝イチにAPPS全体を見渡すセッション
 Topics
 rechartering
 ARTエリア = APPS + RAI をどう反映するか。RAIのDISPATCH的役割をどうす
るか
 IMAPv4rev2
 errataを直す。ポピュラーな拡張をコアに取り込む → 新ML
 Firewalls and WebRTC traffic
 UDPをブロックするプロキシが多い。STUNをうまく通そう
 Mail Divide Framework (赤桐さん)
 メールの種類によって受信サーバーを切り換える仕組み
 Personal Cloud Storage Synchronization
 dropbox, google driveなどのsyncプロトコルバラバラだよね → 横浜でBoF
IETF93報告会2015/08/27
appsawg

httpbis
 概要
 HTTPプロトコルの改良
 HTTP/2, Authorization-Info
 Topics
 HTTP/2はRFC7540, 7541としてpublish(5月)
 Alternative Services
 リクエストに対して、このリソースは他の場所にもあることを伝える手段
 Alt-Svcヘッダ、ALTSVCフレームによって伝達
 キャッシュとそのクリア、パラメータ拡張性などについて議論
 451 Unavailable For Legal Reasons
 法的要請をしているのはサーバかintermediariesか → 452
 その他
 SEARCHメソッド: GET with payload
 Content-encodings: oob コンテンツを他の場所から取ってくる
IETF93報告会2015/08/27

rtcweb
 概要
 Webベースの技術によるリアルタイムコミュニケーションを取り
扱うWG
 IETFとW3Cが連携して標準化しており、IETFでは主にプロトコル関
係を取り扱っている
 Topics
 JavaScriptセッション確立プロトコル(JSEP:Javascript Session
Establishment Protocol)
 ここ数回の大きな話題で1日目は結局JSEPの話に終始、2日目も少しJSEP
 FEC, RETURN, SDP, QoS, gateways
 概ね、前回と同じTopicを話している
 "WebRTC Enterprise Firewall Traversal"
( https://tools.ietf.org/html/draft-jennings-behave-rtcweb-firewall-00 )
はFirewallにシンプルな機能追加をしてSTUNを通しやすくする提案
IETF93報告会2015/08/27

 概要
 ウェブブラウザ向けのPush通知の標準化
 ブラウザが起動していなくてもPush通知可能に
 Topics
 Core Protocolのドキュメンテーションの議論がメイントピック
 Reliability
 Reliabilityは、そのレベルをどこにおくかという視点で激しい議論に
 TTLが有効な限りPushを行い続けることが可能な"Full Reliability"を仕様とすることが
合意された
 TTLがメッセージと確認で同じでいいかの議論が残っている
 Push Crypt
 Choice of Curve - P-256 vs 25519
 TLS 1.3やJOSE(JWE), COSEとの関係を踏まえ議論
 その他、Low Energy RequirementsとSubscription-less WebPushという提案も
 余談：このWGもgithub運用になった
 https://github.com/webpush-wg/webpush-protocol
IETF93報告会2015/08/27
webpush

 概要
 インタラクティブWebアプリケーション向けの、モバイルも視野に入れた
近代的な高品質なビデオコーデックを策定するWG
 " Is viewed as having IPR licensing terms that allow it to be widely implemented
and deployed."
 Topics
 前半は、RequirementsやTest and Evaluation Criteria、Tools and Techniquesな
どの周辺の話がメイン
 後半は、新たにCiscoの"Thor Video Codec" ( https://tools.ietf.org/html/draft-
fuldseth-netvc-thor-00 )のプレゼンテーション
 "Lapped Transform"というDCT(離散コサイン変換)に関する特許回避の為の
仕組みの説明 (詳細はよくわかりませんでした)
 Daalaコーデックで試験的に試されているScreensharing(Screencasting)の課
題解決について
 例えば、フラットなバックグラウンドに上にアンチエイリアスされた文字が載って
いる映像を共有するUse Caseなどできれいに描画する等
IETF93報告会2015/08/27
netvc

SECエリアのWeb関連トピック
 oauth
 dynamic registration → RFC7591, 7592
 token exchange: act-as, on-behalf-ofの実現
 terminologyの議論に長い時間を使ってしまった
 audパラメータの新設など
 httpauth
 MutualAuthが進んでいないのでテコ入れ
 tokbind:トークンを特定のクライアントにbindする
 tls-uniqueに、サーバーに登録した公開鍵で署名する
 http://www.slideshare.net/KaoruMaeda/tokbindfido
 TLS拡張を使ってネゴシエーション(not ALPN)
 hash alg, sig algは番号レジストリに
 拡張性、フェデレーションシナリオの検討、対XHR保護
IETF93報告会2015/08/27

QUIC Bar Bof
 水曜日20:20～22:00
 軽食、ビールつき
 150名くらいが参加
 Intro
 Jana Iyengar: QUIC - Redifining Internet Transport
 Christian Huitema: Implementing QUIC for
Windows
 Ian Swett: QUIC Congestion Control
IETF93報告会2015/08/27

Quick UDP Internet Connections
IETF93報告会2015/08/27
Janaのスライドより

QUICのmotivation
 TCPがデザインされてからインターネットの
状況は変わった
 コネクション成立までが遅い
 slow start
 輻輳制御
 UDPで作り直そう
IETF93報告会2015/08/27

QUIC as HTTP transport
IETF93報告会2015/08/27

QUICの特徴
 TCP + TLS + SPDY を UDP で
 TLS/TCPの接続確立を0-RTT, 1-RTTで
 パケットロスと再送の工夫
 Stream/Connectionレベルのフロー制御
 (FEC: forward error correction)
 (Connection Mobility)
 (マルチパス)
IETF93報告会2015/08/27

1-RTT, 0-RTT
 TLS-1.3の0-RTTと同
じ
 0-RTT
 セッションデータが
あるときは、いきな
り暗号化リクエスト
を送る
 サーバーが知らなけ
ればREJと証明書 →
1-RTT
IETF93報告会2015/08/27
1-RTT
0-RTT

パケットロスと再送の工夫
 TCPの知見を反映した輻輳制御
 TCP Cubic - fair with TCP
FACK, TLP, F-RTO, Early Retransmitなどなど
 Initial Window 10 vs 32
 シグナリングの改良
 再送パケットにもsequence numberをつける
 256レンジのNACK
 受信時刻 → レイテンシがわかる
IETF93報告会2015/08/27

QUICは動くのか?
 Google Chromeに実装(ユーザーランド)
IETF93報告会2015/08/27
92%で動く!

QUICは速いのか?
 ChromeとGoogle Server(主にYouTube)で測定
 ページロードが5%速く
 特にテイルで改善が大きい。99%-tileで1秒
 YouTubeのリバッファが30%減
 0-RTTの貢献が大きい
 75%の接続が0-RTT
 latencyメジアンが50～80%改善
IETF93報告会2015/08/27

QUICの議論
 セキュリティーの問題
 0-RTTのリプレイ可能問題
 リプレイ可能な(べき等な)リクエストでだけ使う
 (MUE draft-hoffman-httpbis-minimal-unauth-enc-01)
 プライバシーの問題
 connection-id (64bit)
 モバイルなどでIPが変わっても接続が継続できる
 逆に言うと同じ人が使っているデバイスがバレる
IETF93報告会2015/08/27

QUICのこれから
 未実装の部分(Mobility, FEC, Multipath)
 IETFでどうQUICを議論するかについては
このBar BoFのスコープ外だった
 QUIC: A UDP-Based Secure and Reliable Transport
for HTTP/2
 draft-tsvwg-quic-protocol-01
 HTTP/2のHPACKを使っている部分でHOL-blocking
 議論はここで進んでいる
 https://www.chromium.org/quic
 ML: proto-quic@chromium.org
IETF93報告会2015/08/27

まとめ
 ARTエリア := APPS + RAI
 HTTP/2がRFCに
 ALTSVCなど拡張の議論に
 旧RAIの議論は時間がかかっており停滞感
 QUICは多くの興味を集めた
 QUICについてはまだまだこれから
IETF93報告会2015/08/27

Any Questions? / Please Feedback!
https://lepidum.co.jp/
mailto:maeda@lepidum.co.jp / twitter: @mad_p
IETF93報告会2015/08/27

IETF93 Prague報告Web関連+QUIC

More Related Content

What's hot

Similar to IETF93 Prague報告Web関連+QUIC

More from Kaoru Maeda

IETF93 Prague報告Web関連+QUIC