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

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

九十四年十一月十四日

報告人

姓名

楊禎葆

葉士豪

服務單位及職稱

工程師

出國期間

九十四年十一月六日至

九十四年十一月一十三日

出國地點

加拿大-溫哥華

出國事由

參加第六十四次 IETF溫哥華會議

報告書內容應包含：

一、出國目的

二、考察、訪問過程

三、考察、訪問心得

四、建議意見

五、其他相關事項或資料

（內容超出一頁時，可由下頁寫起）

授權

聲明欄

本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。

授權人：（簽章）

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

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

一、出國目的

第六十四次IETF會議於九十四年十一月六日至九十四年十一月十一日在加拿大溫哥華舉行。此次會議為期五天，而中心參加之目的主要工作為發起IEE(Internationalized Email and Extensions BOF)，及參加 ENUM WG 會議，並與會中心之相關議題(DNS/DomainKey/Ecrit) 以了解其發展。

二、考察、訪問過程

此次行程於當地時間早上十點(11/06)到達溫哥華，此日為 IETF 之Tutorial ，主要教授一些初次與會者要注意的會議事項，及部份的主題(DNS/Security)教學，由於並非我們所參加的主題故並未與會參加。

次日，正式開始一系列之 Working Group 會議，由於會議是同一時間有多個 WG 同时舉行，故我們僅選擇與中心核心之相關問題參加，故共參加了六場不同之主題。

三、考察、訪問心得

IEE BOF：

Internationalized Email and Extensions BOF也是本次參加IETF最主要的任務，主要討論Internationalized Email相關的技術方案，主要的概念是使用SMTP extension的溝通架構，再加上UTF-8的Email Header來達成Internationalized Email的傳遞，並且在適當的時候進行轉碼(Downgrading)，來保持Email的向下相容性。

會議主席由剛卸任的IESG Chair Harald Alvestrand來擔任，由於先前IMAA失敗的經驗，因此本次的討論集中在單一個解決方案，使用SMTP extension的方式來進行，會議中先由John Klensin做整體解決方案的簡介，再由各draft的作者報告，分別為draft-yao-ima-smtpext-00.txt、draft-yeh-ima-utf8headers-00.txt、draft-yoneya-ima-downgrade-00.txt，接著進行相關討論，其中許多人建議將POP3/IMAP以及MUA Guideline部分加入WG的Charter，成為本WG的一個工作項目；而Email是Internet上的很重要的服務，幾乎可以算為繼基礎建設之一，因此為了維持Email系統的正常運作，在downgrade以及mailing list相關的問題上，亦有建議將此部分放入WG的工作項目，並且同時進行。其他相關的部份像是vCard、Internationalized Email與ALT-address之間的關聯等等亦有被提出，相信在WG成立之後應該會有許多的工作必須要做。

在會議的最後，約有一半的人同意這個問題需要被解決，~~沒有人~~只有一人不同意WG應該成立，並且有約四分之一的與會人員願意投入幫忙，可以算是一個非常成功的BOF，在Charter完成之後會post到mailing list進行討論，接著遞交至IESG，順利的成立WG應該是沒有問題。

dnsop WG

Domain Name System Operations WG，這個WG主要的工作是建立DNS Sever的運作的相關準則，像是Zone File、Root Server、Resolver等等，另外IPv6 DNS以及DNSSEC的運作相關標準，也是此一WG的工作項目。

會議中先報告了先前的Draft進度，其中draft-ietf-dnsop-ipv6-dns-configuration已經進到了RFC Editor，應該再過不久就能夠發佈成為RFC，另外draft-ietf-dnsop-dnssec-operational-practices-06.txt以及draft-ietf-dnsop-bad-dns-res-04.txt也通過了WG的Last Call，還有一篇draft-ietf-dnsop-ipv6-dns-issues-12.txt的進度則是IESG在審視中。接著則是WG目前正在進行的draft討論，包括有draft-ietf-dnsop-serverid-05.txt、draft-ietf-dnsop-inaddr-required-07.txt和draft-ietf-dnsop-respsize-02.txt三篇，其中serverid是講到了越來越多使用anycast / load balancing DNS / Layer 3 switch的DNS server，使得許多的DNS server能夠使用同一個IP位置，但是這也造成了追蹤不易的問題，該篇提出了一個特殊的txt紀錄來作server辨識的功能，而另外兩篇則是講到反解部分相關的建議，及DNS回應的長度相關問題，在這裡不多作介紹。最後討論到一些可能成為dnsop WG的工作項目的相關draft，而draft-andrews-full-service-resolvers-01.txt

這一篇引起較多的討論，該篇提出建議由IANA建立一個專門的Registry來記錄像是RFC1918、RFC3330或者是IPv6相關的特殊網段，讓Name server的管理者可以很容易的取用到這個資訊，以方便作正確的設定。

dkim BOF

Domain Keys Identified Mail BOF提出一個在不更動Email架構和MUA的前提下，對Email發信端進行認證的機制。在draft Charter中有說明到DKIM這個Protocol僅僅提供一個對送信端確認，並不會做任何刪除郵件相關的定義，也不會有類似名聲紀錄(Reputation service)，也不會牽扯到信件內容的一致性(Confidentiality)及加密(Encryption)，該部分應該歸屬在S/MIME，PGP等等相關的領域。

這個BOF提出一個在MTA對MTA之間以網域名稱為基礎的認證機制，來阻擋現在越來越嚴重的SPAM問題，主要的概念是由發信端MTA對信加上一個新的Header，其中包含了該MTA用Private Key簽章過的資訊，而Public Key的部份則是使用DNS中的TXT的紀錄來儲存，以便於收信端可以直接取用，並對該信件加以確認，這個部份的詳細內容在draft-allman-dkim-base.txt這篇ID中有完整說明。基礎的架構圖如下：

而在draft-allman-dkim-ssp.txt這篇中，定義了發信端簽證政策(Sender Signing Policy)，使得網域名稱擁有者可以自行設定簽證的政策；最後在draft-fenton-dkim-threats.txt中則分析了DKIM可能帶出相關的問題。在後續的討論中，許多人質疑DKIM是否真的有用，因為他並沒有定義到沒有被簽證的Email該如何去處理，而SSP的部份也只能幫助一小部份，而另外一個則是當SPAMMER依照著DKIM的方式進行Email簽證之時，DKIM也無法辨識出其中的差別等等，顯示出單單靠DKIM並無法有效幫助SPAM的問題，還是必須要靠著Reputation類似的系統，才能夠進行有效的分類。在BOF的最後，約有三分之一的與會者同意此WG應該成立，另外約有十分之一的人反對WG的成立。

DNSEXT (DNS Extensions WG)，

DNSEXT 主要專注於 dns extension 之發展，例如 DNS 延伸版本、DNSSEC、NOTIFY、EDNS0、TSIG、IXFR/AXFR，本次會議主要討論上次會議以來之 Internet-draft 之更新，並對於巳確定之 Draft （巳通過 Last Call）進行說明，會議上報告了三篇巳通過 WG 相關作業之 Draft ，並等待 IESG 通過即可成為 RFC(此三篇分別為draft-ietf-dnsext-nsid-00.txt、draft-ietf-dnsext-rfc2536bis-dsa-06.txt、draft-ietf-dnsext-rfc2539bis-dhk-06.txt)，並有三篇 Draft 準備進了 Last Call 階段，及四篇至上次會議以來主要變動的 Draft(三篇為 dnssec 相關，一篇為 RFC2929bis)，本次會議則針對此四篇進行了一些討論，該三篇 dnssec Draft 尤於與中心目前較無關故不做介紹，而 2929bis 則是針對了 RFC 2929 Domain Name System (DNS) IANA Considerations 進行了一些修改上的討論，2929 是 IANA 對 DNS Packet Header 的一些說明，主要針對 DNS 不斷演變以來，每一個 header 的欄位意義則其值做了許多描述，並對不同的 Return Code 的值及 Range 做了定義, 因為RFC2929 僅模糊定義了 TYPE 如何提交，而 Draft 2929bis 則對一些名詞做了統一的修訂(也提及 RFC4020 中的一些相關問題)，並明訂新增RR TYPEs, CLASSes, RCODEs, OpCodes, header bits，如何提交相關資料至 IANA，而 Draft 2929bis 則更提出了名確的表格(包含了 Date/Name and email of originator/Pointer to detailed RR description document/Need for new RR Type?/Closest existing RR Type/Does new RR Type require special handling different from an Unknown RR Type)，並建議這個表格中的相關資料應經由相關專家看過(對專家如何產生沒有定義)，並 POST 到 dnsext 相關之 Mailing List (namedropper@ops.ietf.org) 以得到充份之討論並通過後即可成立。

此會議尚討論了許多 DNSSEC 相關之標準，並介紹了一個多方面的 DNS 測試工具(http://www.tahi.org/dns/)。這個 Working Group 主要討論了許多 DNS 的新技術，但有很大工作量在 DNSSEC 的部份，而一般常見的 Extentsions (例如: edns0/Notify/IXFR..) 等因目都巳是定案的東西，目前這個 Working Group 主要的工作多是在 DNSSEC 的相關項目上為主。

ERRIT (Emergency Context Resolution with Internet Technologies)

此 Working Group 主要探討 Internet 之緊急電話(例如 119/110) 之定址技術，如何以該緊急電話中所帶有之資訊(例如 IP、Number) 得知緊急電話之發話人之地理資訊，尤於現有之 Internet 有許多狀況造成定址上的困難(例如 VPN,DHCP,Tunnel)，故造成許多發話人定址之的問題，由於此類技術的困難性及複雜度頗高，自成立 Working Group 以來雖有許多討論，但尚未形成有效之共識，故會議中每個 topic 或 slice都有許多的 Comment。會議開始討論了 draft-schulzrinne-ecrit-requirements-01.txt ，這篇 Draft 主要探討了IP base 的緊急電話相關問題，並鎖定其scheme URI 為 sip/tel，很顯然的，過去兩次會議巳一再Review 過這個 Draft，所以會議中僅探討了兩個 Issue：

Open Issue 15: 緊急電話之功能是要在 Protocol 還是 architecture 中定義?

與會者的 Comment 對於兩者各有支持，主要在於在 Protocol 中定義的話，對於透過 Protocol 來解決是較容易的(需要修改 UAC/Proxy 等，或加入不同的 Header) ，但需要去翻修過去的 RFC 及使用者上線位址有變動時需填寫必要的地址資訊且不能被 Proxy 等 rewrite 功能修改，而且 User 上線時，需對其現在所處地點做輸入，很顯然的會造成使用上的困擾，對於移動中的用戶則更顯不便。若是 architecture 中解決，則建置成本則會很大，且會有誰來維護及較大之維護成本(集中式，分散式，Sensor等)。Architecture solution 因為架構上的問題，還可能面對不同性質上的安全問題，如 DOS攻擊或人為惡意的資料散佈或惡意欄截等。

Open Issue 17:誰該提供位址資訊，是 ISP 還是 VSP (voice service provider)，若提供的位址資訊錯誤應該怎麼辨？

這個問題位場上大家的看法多屬意 ISP應該要提供，只是如何要求其提供可能需要適當的政府力量介入，因為 VSP 可能無法介定 User 用那一家的網路及來源等，而位址資訊的錯誤可能是難免的，對於新的 IP 或剛變動過的IP 如何快速更新到 Location Database 中應該由適當力量來規範方能達到合理的要求。

另外，會議也說明了如何使用其他的的技術來達到定位的功能，例如 DHCP/PPP 等，在網路初始化時，給予像 BOOTP Vendor Extensions and DHCP Options 中適當的 Option 項目，而其包了這個 DHCP 所包含的 Location相關資料，不過就與會者的 Comment 來看，這也是沒有辨法中的辨法之一，因為這些方式尚都不能完全解決問題及取得一致的共識。

本次會議另外列了許多 Issue 供與會者思考建議(http://www.ietf-ecrit.org:8080/ecrit-req/ )，但尤於會議時間並不充足，故未討論到，應該是會留到下次會議再進行討論或在 Mailing List 裏再追踪。

ENUM (Telephone Number Mapping)

本次會議共有兩個 session，但時間埸地上是連續的，故連在一起開了，這次會議有許多主題及內容，以下一一做一些說明:

IANA Registration for Enumservice vCard

vCard 即是一般常用於 SMTP 或 HTTP 中的 electronic business card ，主要儲存一些個人願意公開的資訊或是公司資訊，而 vcard 有一定格式或要求，所以這個 draft 作者主要提倡在 End to End 通話時，可以透過 ENUM 的 vcard 相關記錄，帶出通話雙方的一些資料，例如:




 
  
 
 
  
  
  
   
    
    
    $ORIGIN 4.3.6.1.4.6.5.0.5.1.3.4.e164.arpa.  
    @ IN NAPTR 100 10 "u" "E2U+vcard" "!^.*$!http://www.enum.at/vcard-axelm.vcf!" .

不過這個 Draft 獲得的反響不如作者預期，而會場上多數的 Comment 也覺得 vcard 用於 enum 中將有隱私上及安全上的問題，也容易造成他人的不法收集或謀利。

IANA Registration for IAX Enumservice

IAX (Inter-Asterisk eXchange ) 是由著名的Asterisk (主要用在 Linux/Unix Platform 的 PBX) 所提出的一套 VoIP 交換方法，其可使用一般的 sip 或 h323 的 uri，而這個 Draft則是提倡 IAX 在媒體串流技術在上的應用如何搭配 enum，其格式為:




 
  
 
 
  
  
  
   
    
    
    $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
    @ IN NAPTR 10 100 "u" "E2U+iax" "!^.*$!iax2:example.com/charlie!" .
    ；格式為 iax2:[username[:password]@]host[:port][/number[@context]]
    ；

這個報告在會上並沒有任何的 Comment，不過感覺起來因為 IAX 因為僅是特殊領域使用，而非通用標準，故要通過成為通用的 scheme 似乎可能性不大。

ENUM Implementation Issues and Experiences

這個報名主要提供了一些ENUM 開發及實作上的問題及經驗，因為實作上有些容易混洧的地方，故幾乎針對了每個環節做了些說明，這些 Issue 在我們推廣 SIP/ENUM 或 APEET 時有時也會困擾著我們，主要的 Issue 如下:

1.     NAPTR 對 multi-byte 的處理支援不足，建議適當的增加sub-field以利判別 uri 是 single byte 或 UTF-8，不過這會和 IDNA 及 IEE 有所關係，因為 IDNA 要求的是 DNS 為 7bit 資料，而 IEE 則取向 UTF-8 的 Local-part，或Downgrade 為 punycode，這個問題是值得後續追踪的。

2.     tel:+886223411313 中的 + 號或任何 syntax 有關於 Regexp (例如 ! \ $ {}()…)部份應該在前面加上 escape (\) 以利 regexp 判別其為字元或 regexp，對於不對稱的 regexp 或 ! 應該視為該筆 NAPTR 無效。

3.     對於有發生迴圈或遞迴情形的 NAPTR 記錄，應該要避免，若不能避免，其建議深度或次數要小於５，也就是一個發起的 ENUM query 應該最多只遞迴五次。

4.     DNS Packet size 在一般情況下不能超過512 bytes, 不然會有truncated 情況產生（DNS header 中的 TC=1），如果使用 TCP 來查詢 ENUM DNS 或 EDNS0 就不會發生這樣的情形，不過這樣的情形不能保證在整個 DNS Query 過程中，所經過的每個 DNS server 都支援 TCP query 或 EDNS0，而一般若在 truncated 情況下，會造成改用 TCP Query，也就可能造成了整個 Query 的失敗發生。




 
  
 
 
  
  
  
   
    
    
    ;; Warning: Message parser reports malformed message packet.
    ;; Truncated, retrying in TCP mode.
    ;; Connection to 210.17.9.240#53(epp.enum.org.tw) for 9.0.9.0.3.0.4.4.9.0.e164.tw. failed: connection refused.
    #這是目前 basic query 上的結果，而多數的 dns server 僅支援 basic query

5.    對於 RFC 2916 及 3761中ENUMservice 中的不同 (Service Type 欄位)，因為巳經有很多舊的ENUM DNS 都用舊的方式，其建議 ENUM Client 兩者都要能夠支援，因為 2916 的格式還有很多人在使用，不能說 2916 巳被取代掉了而不支援。

ENUM Requirement for EDNS0 Support

這個議題主要呼應上一個主題中第四點的 truncated 的問題，而 enum query 不使用 TCP 的理由除了不能保證每個節點都支援外，另一個因素則是 tcp hankshaking 較慢的問題，RFC2671 定義了EDNS0 可以使用較大的 payload size(這個因素還是會受 network 的 MTU 影響)，同時間仍使用 UDP 協定，DNS 採用 UDP Query 能夠有效佳的工作效率，而 TCP 除了較慢也較耗系統的資源，這個報告最後也提及了這個需求可能要和 dnsop 及 dnsext WG 做適當的討論。

Carrier/Infrastrucure ENUM Requirements

Carrier ENUM 之主要議題在建立一個 Carrier 間透過 ENUM 的 NAPTR 記錄做 PSTN Call 的交換，而這個交換主要希望能夠在一個 private 的環境上不同的 carrier 間的 PSTN交換，而這個交換的要求是所有的 Query 必需被受理，不可以是拒絕連接的狀態，至於 Query 後返回的東西可以是 Rrset 或是查詢後所返回的 DNS Rcode(意即　NOERROR/ NXDOMAIN/ NXRRSET….)。而這個會議也再次強調了要在同一個 TLD 下進行 Carrier ENUM，這個 TLD 目前是 e164.tw，也強調了對 ENUM Record中對穩私權的保護問題，只是如何保護似乎沒有特別說明。而這個 Carrier ENUM 最重要的要求是儘量減低對 RFC 3761 變動的影響、建議在共同的 numbering plan 下作業(E164 number or IP Number)、、以最少量的查詢並達到最多回應的結果、精簡 Client 端必要的資訊、最大化 user enum 的共同性、建立一個能在 Carrier 間互連互通且 private 的 Enum Tree。

對上述的建議，有人提出了利用 BIND 9 View 的特性，建立一個Carrier 間共同的 Enum Tree，並且彼此在這個 View 中處於信任的區間，如此在解析的效率，解決問題的程度，及不同 Carrier 間的公平性及經濟效益能夠發揮最大的效果。

關於 VOID 的使用，Draft 提出了關於 NAPTR query 若返回 NXDOMAIN (Not eXist Domain)時，由於可能是該號碼巳使用但未註冊ENUM，或是該號碼是尚未使用，而希望對尚未使用的部份做一規範，這個規範的 ENUMservice 名稱即是 VOID其格式為:




 
  
 
 
  
  
  
   
    
    
    $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
    3.8.0 NAPTR 10 100 "u" "E2U+void:mailto" "!^.*$!mailto:num-drama-info@nra.cc.example!" .
     
    $ORIGIN 1.6.9.2.3.6.1.4.4.e164.arpa.
    4.8.0 NAPTR 10 100 "u" "E2U+void:http" "!^.*$!http:\/\/www..cc.example\/numbers\/index.html!" .
     
    $ORIGIN 2.6.9.2.3.6.1.4.4.e164.arpa.
    4.8.0 NAPTR 10 100 "u" "E2U+void:https" "!^.*$!https:\/\/connect.cc.example\/numbers\/secure.html!" .

如此，當 Carrier 查詢到該 NAPTR 所帶 ENUMservice為 void 時，即可以知道該號碼尚未使用，及該號碼必要的管理資訊，這個資訊可以是一個 mail/http/https 的uri。由此可知，若要參與交換的 Carrier 必要將其所有 number 的 NAPTR 記錄建立出來，不論其為 User 有沒有使用 ENUM 或是尚未發放的號碼。就其 Draft 中所指含義，似乎有些混洧不清的感覺，主要是 NAPTR 的表示和描述似有不同之處。

ENUM Validation

Validation 共有二篇相關的 Draft，由於其主要和 EPP 有關，其強調 ENUM Doamin 並不同於一般的 Doamin Name 對先來先申請的原則，故要 Registrar 在人和號碼的關係有一定的關係，意即要能知道該號碼是不是屬於實際擁有者，故建議 Registrar 一定要確認過，而確認過的的資料在 EPP 向 Registry 傳送時要加入適當的VE( Valition Entity) 欄位(xml element name)及 Validation 時間，例如 validationEntityID ，serial 等，如下例:




 
  
 
 
  
  
  
   
    
      <?xml version="1.0" encoding="utf-8" standalone="no" ?>
   <token xmlns="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation=
     "urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd">
     <validation serial="acmeve-000002">
       <E164Number>+43780837842</E164Number>
       <validationEntityID>ACME-VE</validationEntityID>
       <registrarID>reg-4711</registrarID>
       <methodID>42</methodID>
       <executionDate>2005-10-06</executionDate>
       <expirationDate>2006-01-01</expirationDate>
     </validation>
   </token>

至於每一個詳欄位的意思可見於 draft-ietf-enum-validation-token-00.txt Section 4.1 的部份，其主要的用意即在於 Validation 這個 Number 的狀態，因為就現實情況來說，有可能號碼會由某一人移轉到另一人身上或有停用，號加減碼的情形，故有一個 Validation 機制能確保號碼和人的關係，其主要精神即在於此。

四、建議意見

1.        建議持續追蹤IEE發展，並可在技術方案較為確定後進行測試系統的建置，以利後續開發及討論的參考。

2.        由於DNS運作為中心核心業務，建議持續關注dnsop相關進展。

3.        Domain Key的架構並不能有效阻擋SPAM，但可以繼續觀察。

4. ECRIT WG 雖僅是剛成立不到一年的 Working Group，不過是此行所見最多聲音的 WG，因為這個 WG 也明說不能可有完全的方案，僅能就不同的情況提出建議的方案，而這個 WG 目前各方面都還有很大的參與空間。

5. 本次會議僅討論了兩個 issue，但 Requriement 中提到的東西還有不少未解決，而 ietg-ecrit.org 上也有適當的 issue 整理，中心可就 Requriement 及該 URL 中提到的一些東西集思廣義。

6. DNSEXT 中關於 2929bis 中，關於 Standards Action required allocation policies 可以再做適當之研究及討論。

7. ENUM WG 中 Validation/Vcard/IAX2 從會議上可以感覺到較不重要，而 ENUM Implementation Issues and Experiences 確實也是 SIP/ENUM Trial 中所碰到的一些 Issue

8. ENUM WG 中對於 DNS 支援EDNS0 會強烈需求，而此問題確實也存在我們的系統中，也值得計畫或中心適當的探討。

五、其他相關事項或資料

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

http://www.ietf.org/meetings/IETF-64.html