財團法人台灣網路資訊中心因公出國人員報告書

九十六年三月二十八日

報告人 姓 名	許乃文 楊禎葆	服務單位及職稱	組長 工程師
出國期間	九十五年三月十八日至 九十五年三月二十三日	出國地點	捷克 布拉格
出國事由	參加第六十八次 IETF布拉格會議 報告書內容應包含： 一、出國目的 二、考察、訪問過程 三、考察、訪問心得 四、建議意見 五、其他相關事項或資料 （內容超出一頁時，可由下頁寫起）
授 權 聲 明 欄	本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。 授權人： （簽章）

附一、請以「A4」大小紙張，橫式編排。出國人員有數人者，依會議類別或考察項目，彙整提出報告。

註二、請於授權聲明欄簽章，授權本中心重製發行公開利用。

一、出國目的

第六十八次IETF會議於九十六年三月十八日至九十六年三月二十三日在捷克布拉格舉行。此次會議為期六天，而中心參加之主要目的為參加 EAI WG (Working Group) 標準討論EAI (Email Address Internationalization )，及參加 DNS 相關之 WG 會議，並參與會中心之相關議題(DNS/DomainKey/Ecrit) 以了解其發展。

二、考察、訪問過程

此次會議雖期程共六天，行程安排，我們僅參加五天的會議，重點參加必要之 WG，所以共參加了五個 WG分別為 DKIM、ECRIT、DNSEXT、EAI、DNSOP。

所到第一日是中午, New Comer 的 Training，因為過去都曾參加過，故我們沒有參加此一教育訓練課程，而稍做整埋後，稍加了解了一下週圍環境。次日，正式開始一系列之 Working Group 會議，由於會議是同一時間有多個 WG 同时舉行，故我們僅選擇與中心核心之相關問題參加，故共參加了五場不同之主題。

三、考察、訪問心得

ERRIT (Emergency Context Resolution with Internet Technologies) 

此 Working Group 主要探討 Internet 之緊急電話(例如 119/110) 之定址技術，如何以該緊急電話中所帶有之資訊(例如 IP、Number) 得知緊急電話之發話人之地理資訊，尤於現有之 Internet 有許多狀況造成定址上的困難(例如 VPN,DHCP,Tunnel)，故造成許多發話人定址之的問題，由於此類技術的困難性及複雜度頗高，自成立 Working Group 以來雖有許多討論，但尚未形成有效之共識，故會議中每個 topic 或 slice都有許多的 Comment。

本次會議報告了第二屆“SDO Emergency
Services Coordination Workshop” 將於 Washington D.C 舉行的訊息，這個 Workshop 主要在實現目前 ECRIT 的 draft 所提出來的各種做法及問題，目前 WG 最主要的工作就是找一個能普遍為各接受的方案。而這個 Workshop 另一個重點在於 ETSI 及 ITU-T 都參與了這個會議並提供了一些看法，並表示其亦在研究 IP Network 的緊急電話問題，個人認為這個領域隨著 VoIP 發展會顯得愈來愈重要。

除了 Workshop 的 Issue 外，本次會議的另一個重點是 LoST (A Location-to-Service Translation Protocol) 的 Draft　的討論，這個 Draft 經過三次 IETF 會議以來的討論目前巳漸被廣為接收，並提供了必要的緊急電話服務的格式及資訊，會議上咸認因為 Internet 使用上不向一般傳統的的電話線路可以很容易找到 Location 資訊，雖然 IP 在定址上有一定的困難，但交換的資訊必需是統一的，好讓 PSAP (類似 119 勤務中心)可以在接通電話時，儘可能知道必要的資訊。
會議上 TIA 另外報告了 IEEE 的新標準 LLDP-MED (The Link Layer Discovery Protocol-Media Endpoint Discover)，這個標準主要在各個 IP 設備在上網時，應該對其鄰居進行埠號標識、系統名稱、系統功能、系統描述及其它屬性進行說明及註冊，以利在這個設備有問題時可以及時找到它，這個需求可以應用在 ECRIT 的位址定址上。
LoST (A Location-to-Service Translation Protocol) Draft 在 UA 的定義和 Proxy 上的定義似乎描述的不夠清楚，如此會讓 PSPA 不容易找到人，會議上則有人建議這個問題 Draft 應該有更清楚的定義，而主席則裁示這個問題應回到 mailing list 上多加討論及舉例，才能有更清楚的結果。
會議上的報告也提到了使用 ENUM 來搭配緊急電話的使用，將緊急電話對應到 PSAP 的 URI 上去，好讓不同地區或是不同國家的緊急電話可以互連互通，不過這面細節問題仍可能很多，因為會議時間僅有一個小時，故主席亦裁示留待 mailing list 上討論，而且請有興趣的人可以提出相關的Draft 以利討論的進行。
 

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 政策為何，此 Draft 之重點主要在於文字上可能需要加強一些Scenario 的說明，及可能發生的攻擊因素和預防措施；另外，SPP 也建議使用不同的 DNS TYPE 來做 DKIM 想做的事，因為太多協議都可能使用了 TXT 記錄，舉例了像 DKIMP或 XPTR等，或使用 PTR 於 DKIM 上也可以，不然就是需要為 DKIM 加上一個特定的 prefix (ie: _domainkey,_policy._domainkey 等等)，如此雖可解決問題，但總不如 DKIMP 等來得明瞭。會議上另外報告了兩個可能的攻擊方法，一個是 DK 的記錄 a= (演算法)不符合定義時的處理因素，這種狀況下與會者一致認為若 Dns query 時得到的Key 不符合 a= 的要求時，應該忽略這個簽章，以避免無謂的消耗；另一個問題則是一封郵件被 signing 兩次時，此時的問題應以新的簽章為主或是舊的為主，依照目前 Draft 的要求，與會者則多認為應以上面(即新的)的簽章為確認對象，而忽略舊的部份，以避免確認上的問題發生。
 
 
DNSEXT WG (Domain Name Service EXTension)

DNSEXT工作組討論幾個DNS相關draft之進行情形，其中比較重要的是DNAME的改版，由於DNAME在現有DNS的RR中算是比較有爭議的一個RR，對DNS server效能、安全性的影響也較大，再加上ICANN IDN TLD的進行也有部份因DNAME的問題而延後其進度，因此此次DNAME改版備受注目。

一些在舊版中沒有提到的細節在這次改版中都會加以清楚定義，如wildcard的使用是不限制的但不鼓勵使用。其它例如signaling問題、Compression in DNAME RDATA、…等在新版標準中會作修正，,細節詳見http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-01。

另DNSSEC的主要標準皆已制定完成，但要完成全球布署要一些時間，尤其是root server更是要更久的時間。因此工作組後續的工作是要推廣DNSSEC，在工作組上報告了進度及工作項目，詳細可參考: http://www.dnssec-deployment.org/

 
 DNSOP WG (Domain Name Service Operation) 
此 WG 本次討論之重點在於TTL、DNSSEC、AS112 (意虛擬IP網段)之問題。TTL 問題主要在探討 TLD 在不同的 TTL 時間因素下，遭受可能的攻擊或大量查詢時的影響，並進行了圖表化的分析工作；DNSSEC 查可能會受 Resolver 預設不支援援 EDNS0 所影響，造成解析需轉化成 TCP truncated 模式，這些問題可能在 DNSSEC 的推廣上造成一些影響；AS112 則是指因為現在多數人或多數公司都有使用到 Private IP，而這些 Private IP 所用的 Resolver DNS 並沒有設定這些 IP的的反解資料，所以許多虛擬 IP 反解查詢到送到的 Root 等去進行查詢，講者說明這樣的情況仍然很普遍，建議先從 ISP 的 Cache-Only DNS 著手，再慢慢的推廣到一般公司。至於此 WG 其他討論的主題則較流於一般，像 DNSSEC 或 Resolver 等，感覺起來到實現恐怕仍有一段不少的路要走。
 

EAI WG (Email Address Internationalization Working Group)

這個 WG 是中心目前參加 IETF 會議中的重點項目，主要在討論 Email Local-Part 中使用 UTF8 編碼的一些方法，尤於影響層面蠻廣的，所以細節問題亦不少，這次會議討論了一些目前 EAI WG 發展的近況，主要工作如下：

1. John Klensin 所撰寫之 framework 巳經通過 IESG 的審核，可望於近日內公布為 Information RFC。

2. CNNIC 所撰寫之smtpext 需要補強一些說明資訊，以便更加清楚 extension 之運作原理。

3. TWNIC 所撰寫之 utf8header 目前沒有任何異議。

4. DSN draft 因為是初版，故討論的較多，其中對於message type 經由投票表決將使用 message/utf8smtp，對於 Local-Part 的編碼使用百分比方式 (%Hex) 或 Unicode (\uUnicode) 方式目前仍無定見，可能需要在 mailing-list 上有更多的討論。

5. JPRS 所撰寫之downgraded 草案是本次會議之討論重點，主要因為 Domain Key 機制將會影響 downgraded 之進行，且可能存在 upgraded 之情形，故需要決定一些運作機制：

5.1 對於 Downgraded 的運作應保留完整的必要訊息，不能影響 DKIM　之 sign/verify 之運作。

5.2 Upgraded 訊息主要用於查看表頭資訊及回覆郵件時使用，次之才考量 DKIM 之需要。

5.3 對於 uFor 欄位的刪除動作應該有更明確的流程與資訊說明，以避免不必要之錯誤，此問題將持續於 mailimg-list 上討論之。

5.4 最後終端系統可能需要進行 upgraded 動作，有可能由 MTA 做，或 POP/IMAP 協議來進行 upgraded 之處理

6. IMAP 協議將以 enable 方式來進行 EAI 的實作，而不以新的命令方式進行。

7. mailing-list 之相關協議亦應考慮 upgraded 之可能性，不能單純僅以只有 downgraded 存在思之；對於 list-* header 存在 downgraded/　upgraded　時，應該適當的以 ‘forward-looking’ 欄位加以識別。

下次 IETF 會議將於芝加哥舉行，對於本次會議未決之事項先於 mailing-list 上討論之，若仍未決於下次會議再進行討論與決議。
 
 
 
 
 
 
 

四、建議意見

1. EAI WG 發展目前巳進入部份 Draft 快 Last Call 的階段，而中心 utf8header 則將可能是第二篇，故目前仍需投入較多心力在 mailing list 上的追蹤及意見表達。
2. DNSEXT/DNSOP 目前討論的東西惟 DNAME 可能和中心有較大的相關，建議對 DNAME 的相關討論仍持續 Follow up。

3. ECRIT 感覺目前巳和中心過去關注的 Location Awareness 有段差距，建議改專注於 GROPRIV WG，而放棄 ECRIT，因為 GEOPRIV 討論的東西都是和 IP 或設備的定位相關的。

4. Domain Key 實作及實施程度上可能不如 SPF 來得好，而 SPF 目前巳成為標準，建議日後中心相關的教育訓練可以留心此處，感覺起來 DKIM 似乎目前弄得稍複雜了，而他和 SPF 做的事情並相差無幾。

五、其他相關事項或資料

有關第六十八次IETF會議議程及相關會議資料請參考(Agenda/ Session/ Presentations)：

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68