財團法人台灣網路資訊中心因公出國人員報告書
九十六年八月一日
|
報告人 姓 名 |
楊禎葆 |
服務單位及職稱 |
工程師 |
|
出國期間 |
九十六年七月二十一日至 九十六年七月二十八日 |
出國地點 |
美國 芝加哥 |
|
出國事由 |
參加第六十九次 IETF芝加哥會議 報告書內容應包含： 一、出國目的 二、考察、訪問過程 三、考察、訪問心得 四、建議意見 五、其他相關事項或資料 （內容超出一頁時，可由下頁寫起） |
||
|
授
權 聲 明 欄 |
本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。 授權人：
（簽章） |
||
附一、請以「A4」大小紙張，橫式編排。出國人員有數人者，依會議類別或考察項目，彙整提出報告。
註二、請於授權聲明欄簽章，授權本中心重製發行公開利用。
一、出國目的
第六十九次IETF會議於九十六年七月二十二日至九十六年七月二十七日在美國芝加哥舉行。此次會議為期六天，而中心參加之主要目的為參加 EAI WG (Working Group) 標準討論EAI (Email Address Internationalization )，及參加 DNS 相關之 WG 會議，並參與會中心之相關議題(DNS/DomainKey/Geopriv) 以了解其發展。
二、考察、訪問過程
此次會議雖期程共六天，行程安排，我們僅參加五天的會議，重點參加必要之 WG，所以共參加了四個 WG分別為
DKIM、GEOPRIV、、EAI、DNSOP。
所到第一日是中午, New Comer 的 Training，因為過去都曾參加過，故我們沒有參加此一教育訓練課程，而稍做整埋後，稍加了解了一下週圍環境。次日，正式開始一系列之 Working Group 會議，由於會議是同一時間有多個 WG 同时舉行，故我們僅選擇與中心核心之相關問題參加，故共參加了五場不同之主題。
三、考察、訪問心得
DKIM WG (Domain Keys Identified Mail)
DKIM WG 主要在設計一套 Email 認證的方式，以減少 Spam Mail 的判讀問題，這個做法主要在 MTA 端發生，而不影響目前的 MUA，MTA 在發送信件時以自己的
Private key 對表頭 (Mail Header) 加密計算，產生一組簽章，收信的 MTA 在收到信件時，以 DNS 查詢的方式取得發送端的 sha publick key，進行還原處理，處理後與發送端的簽章進行比對是否一致。
這個做法其實和 SPF 有點類似，而 SPF 則直覺許多，DKIM 需要有簽章及驗證動作，可能會使用到較多的系統資源，對於惡意的攻擊容易形成
DOS 狀況，這是目前 DKIM 最大的缺點，而表頭處理確實能有效驗證發送者身份，只要進行 DKIM 的檢查，即可決定對進件的處理行為是拒收或接收。
本次 DKIM WG 會議主要討論之重點在 SPP ( Signing Practices Protocol)，SPP 是一個第三方資訊主要在說明這個Domain Signing 政策為何，這次的會議中討論了移除粒狀分布問題以避免不必要的負擔，使用 DKIM 中的 p= 指示第三方簽章的認證方式；此外，因 SPP 資訊存放於 DNS 資料中，故依據 Mailing list 中的討論允許使用萬用字元 (*) 及一般的 DNS 搜尋；而作者也認為目前的 SPP 可能仍需更多的討論以取得共識。本次會議同時也決定了不使用新的 DNS TYPE 於 SPP 中，以避免過多不必要的複雜過程，而僅使用一定的字首(prefix) 用於 SPP 中，例如 _spp._domainkey.example.com 等。此外，SPP 也鼓勵能在上層的 TLD 或 SLD 上存放 SPP 的資訊，如此更能有效的實作 SPP 之意義。會上，作者也介紹了 SPP 整個處理流程，雖說作者說 SPP 僅是一個簡單的概念，但似乎看起來還有些複雜。
會上，也特別的再介紹了一次 DKIM Overview，主要因為此篇在本次會前剛剛成為了 RFC，也特別把 DKIM 未為在推廣上可能會遇到的問題做了說明，雖說 DKIM 概念性非常好，但實作面恐怕對不少 Mail Admin 也會有不少的困擾，這個也是 Working Group 要共思解決的。
DNSOP WG (Domain Name Service Operation)
此次 Working Group 會議討論了 Anycast
之佈建要點的 Draft，這是一篇在說明 Roots, ccTLD , RIR 等組織在建構 DNS 的 anycast 時需注意的事，主要條列了各種需要考慮到的現況。此外，draft-ietf-dnsop-resolver-priming-00.txt
則談了 dns resolver 的一些狀況及處埋方法，本次會議其主要建議希望 Root Server ( or ccTLD) 可以提供足夠的 AAAA 記錄，要讓 IPv6 的主機在做名稱解析時，能有更多的選擇，同時也是考慮了 DNSSEC 的施行，在上層的 DNS 中提供 IPv6 的 DNS 主機則更顯得重要，本篇還介紹了一些 DNSSEC 在 Resolve 時的一些實作問題及 TTL 不一致時的處理方法，從各個層面來考量 Resolve DNS 的一些原則。另一個關於 AS112 (也就是關於 Private IP 的 AS number) Draft 則進入了 Last Call 中即將結束，相信在不久的將來其將會成為新的 RFC。會上也介紹了 DNS2DB 的介紹，這個主要是關於將 DNS 的 zone file 存放於資料庫時的效率分析。Nominet 則針對了自身 Freeware 的 DNS 軟體做了介紹，主要別於 Windows 和 BIND 的一種
DNS Server。
GEOPRIV (Geographic Location/Privacy
這個 Working Group 是個人第一次參加，而過去則都是參加 ECRIT，主要因為過去所參加的 ECRIT 較不符合中心關於 IP Location awareness 之需求，故改參加了 GEOPRIV，相對來說 GEOPRIV 則相當符合關於 IP 的實體位址位置的需求。
GEOPRIV 目前最重要的 Draft 則當屬於 DHCP 的定址，這個 Draft 主要在說明如何透過 DHCP 的位址發放時，加入地址和關於位置的相關資訊，由於現有的 DHCP Option 並不支援這個功能，所以需要新的 Option 來提供這個功能，而這個功能因為 DHCP 的 IP 發放對於實際位址仍有很大的空間，在難以解決的技術問題上，此方法仍不失為一個好方法。此 Draft 的要議則是在本篇所所提供的 Option 中，有一個一關於位址資訊的 URI，DHCP 在發放 IP 時則將此 URI 資訊帶給 IP 的要求者，而此設備可能是電腦或相關的週邊設備，也有可能是 IP
Phone 等等，這些設備要能儲存這個資料或填入所要求的一些資訊，經由這個 URI，當別人需要這個設備的位址時，透過 DHCP Server 來進行查詢，則可以知道設備的存放位置。draft-barnes-geopriv-lo-sec-00 則介紹了如何使用 XML 來表示地址的相關資訊，這些資訊可經由其他的協定來表現，以供需要端來使用及分析。此外也有以 HTTP 或 SIP 等相關的欄位來提供地址資訊的相關方法，這些方法或技術各方也了解有其限制，仍無法解析這個
Working Group 相關的需求。
EAI WG (Email Address Internationalization Working Group)
這個 WG 是中心目前參加 IETF 會議中的重點項目，主要在討論 Email Local-Part 中使用 UTF8 編碼的一些方法，尤於影響層面蠻廣的，所以細節問題亦不少，這次會議討論了一些目前 EAI WG 發展的近況，主要工作如下：
1. John Klensin 所撰寫之 framework 巳經通過 IETF 的審核，並於前幾天共布為新的 RFC 4952。
2. CNNIC 所撰寫之smtpext 經過修改後，在本次會議上通過，並於二週內提交正式版之 Draft 以進行 Last Call。
3. TWNIC 所撰寫之utf8heder 經過修改後，在本次會議上通過，並於二週內提交正式版之 Draft 以進行 Last Call
4. DSN draft 經過會議討論也將 Last Call，因為這一篇經過 updatd 的次數較少，與會者有人也建議可以晚一點，不過由於會議記仍未出來，故實際是否進入 Last Call 個人亦不清楚。
5. POP draft 因為經過討論的次數較少，故仍暫不考慮 Last Call。
6. JPRS 所撰寫之downgraded 草案是本次會議之討論重點，主要因為 Domain Key 機制將會影響 downgraded 之進行，且可能存在 upgraded 之情形，故需要決定一些運作機制：
5.1 Downgrade 需對 DKIM 中的 “simple” 方法進行特殊處理，以便在 upgrade 還原時能保持一致性。
5.2 Downgrade 對於巳 MIME 化的 ALT-ADDRESS 不需要再進行其他處理。
5.3 對於 Draft 目前所提示的 Downgrade: 表頭，因其出現太多，對於一般程序而言會較難處理，故建議改以 Downdrade-原來表頭 來代替。
5.4 此外，為因應過度時期，在 EAI 在推廣初始，一些 EAI 所新加的表頭，可以用 X-Header 的方式呈現。
5.5 對於 DKIM 相關表頭的處理因為細節較多，建議與 DKIM Working Group 取得更多的橫向連絡後再進行 Updated。
7. 其他 Draft (POP、IMAP、Mailinglist) 仍進行少量 Updated。