[TOC] # 相關連結 [IETF 118 Meeting Agenda](https://datatracker.ietf.org/meeting/118/agenda) [notes](https://notes.ietf.org/notes-ietf-118-ipsecme) [recording on YouTube](https://www.youtube.com/watch?v=8F_vnb6IGcQ) [session recording](https://play.conf.meetecho.com/Playout/?session=IETF118-IPSECME-20231109-1200) # IETF 118 Prague 4 Nov 2023 - 10 Nov 2023 第 10 組 組員: 官劉翔、陳文獻、林佑儒、林哲玄 ## 選擇的Area、Group名稱及討論內容? - Area: SEC - Group: ipsecme - 討論內容 IP Security Maintenance and Extensions ## 選擇此Event的原因、動機? 因為感覺很有趣。網路安全方向的東西也比較少接觸到,可以補充上課所學。 ## 是否有參加此Group的Mailing list? 有參加,常常討論一些很有趣(好像有點無關又有點關係)的事情。 ## 會議流程紀錄 - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (5 min) - Adoption calls (5 min) - draft-liu-ipsecme-ikev2-mtu-dect - draft-mglt-ipsecme-dscp-np - draft-mglt-ipsecme-diet-esp - draft-mglt-ipsecme-ikev2-diet-esp-extension - draft-smyslov-ipsecme-ikev2-cookie-revised - Other items - Issues with DH with IKEv2 and rekeys (15 min) Paul Wouters - QR alt update (10 min) Valery Smyslov - Update of multiple sequence counters (10 min) Steffen Klassert - Anti-replay sequence number subspaces (10 min) Pierre Pfister - Beet mode (10 min) Antony Antony - Esp trailer adjustment (5 min) Wei Pan - Delete info (5 min) Paul Wouters - RISAV update (5 min) Yangfei Guo - AOB + Open Mic (5 min) ## 會議內容記錄 - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - 主持人提醒參與者注意會議記錄,有人已經擔任記錄員,並邀請其他人給予一些comment - 確認議程,開放對議程的任何意見或修改 - Document Status - Chairs (5 min) - There has not been any emails about the one document we have in the WGLC, so please review it and send comments to list - Adoption calls - Chairs (5 min) - draft-liu-ipsecme-ikev2-mtu-dect - draft-mglt-ipsecme-dscp-np - draft-mglt-ipsecme-diet-esp - draft-mglt-ipsecme-ikev2-diet-esp-extension - draft-smyslov-ipsecme-ikev2-cookie-revised - 此部分沒有人有異議 - Other items - Issues with DH with IKEv2 and rekeys - Paul Wouters (15 min) - Diffy Helman group的實現中,特別是在initial exchange中,如果Child SA和IKE SA的 Diffy Helman不同,可能導致一些cosistent問題,並提出兩個解決方案 - 禁止在IKE和child SA之間使用不同的Diffy Helman - 初始交換中使用通知來提前宣告child SA將要使用的Diffy Helman,chair認為這方式容易使問題被察覺 - 在initial exchange後難以確定對方是否要進行PFS,可能導致實現中配置不一致的情況。為了解決這些問題,提出"No Proposal Chosen",以更好地指示錯誤狀態。同時,Pual也延伸原本的問題,在initail child SA的RKEY時可能出現的困難,以及在添加第二個child SA時可能引起的情況。 - 但因為PFS是非強制性,所以當一方希望使用PFS而另一方不想使用的情況,解決方案還是會被限制。 - 最後,提到了對於同一Diffy Helman group使用不同參數的情況,導致在協商IA之後,ESP會將所有初始參數都發送給對方,這也是需要解決的問題。 - QR alt update - Valery Smyslov (10 min) - Valerie提出了有關在PPK的一種替代方案。原本RFC 8784的PPK,因設計原因,它僅用於保護 initial child SA或IA。 - 他提出的替代方案,使inital ike SA能夠受到PPK的保護,並進行了一些修改包括更清晰的協議和協議中PPK的使用方式 - 這樣的更新也或許可以成為量子密鑰分發(QKD)的一種解決方法 - Update of multiple sequence counters - Steffen Klassert (10 min) - Chair提到目前 Encapusalating Security Payload (ESP) protocol必須有所成長,並提出遇到的四個問題 - replay protection and packet reordering - Header and Trailer format 似乎不太適合today usecase - 提到在More trailer field to the header的利弊 - alignment challenges in high-speed networks - demand for inner transport header visibility in software-defined networking (SDN) environments. - 其中也提及可能的三個解決方向 - adjusting the ESP protocol - Using an encryption offset - leveraging existing extensions like Rapid ESP and WireGuard. - Encapusalating Security Payload (ESP) protocol 在某些使用情境下因為安全、功能、計算時間等原因而無法發揮最大的潛力。 - 這些情境可能各部相同,但是都可以用下面三種方法解決: - fine-grained sub-child SAs - adapting the ESP header and trailer format - allowing parts of the transport layer header to be unencrypted - 這段沒有提出 ESP 個改變,而是解釋了相關情境、詳細說明可能的修改、蒐集這些修改的正反意見、討論這些想法可能的影響 - - Anti-replay sequence number subspaces - Pierre Pfister (10 min) - 討論了在多核心計算環境執行 anti-replay 的 IPsec 的時候,封包的順序可能會被重新排成錯誤的順序 - 例如在多個 IP path 或 traffic-engineered path 使用 QoS class - 提出新的解決方法,把 anti-replay sequence 空間切成多個子空間。 - 看起來被有點狠的打槍了 - - Beet mode - Antony Antony (10 min) - 提出新的 IPsec ESP 模式:Bound End-to-End Tunnel (BEET) mode - 不只實現了現有的 ESP tunnel 和 transport (甚至表現得更好)還加強了端對端的 IPsec - BEET 是為了適應不斷演變的 ESP 應用 (minimalist end-to-end tunnel, mobility and multi-address multi-homing) 而提出的 - - Esp trailer adjustment - Wei Pan (5 min) - 使用硬體實現 IPsec 是提高 throughput rate 的一種方法,但是其中有個挑戰來自現在的 IPsec ESP (Encapsulating Security Payload) 封包設計中 ESP trailer 的位置,這會增加需要的計算時間和資源。這段提出了這個問題可能的解決方法。 - - Delete info - Paul Wouters (5 min) - 在 Internet Key Exchange Protocol Version 2 (IKEv2) 定義 DELETE_REASON Notify Message Status Type Payload 以支援加入刪除 IKE 或是 child SA 的原因 - - RISAV update - Yangfei Guo (5 min) - RISAV is an RPKI and IPsec-based AS-to-AS approach for source address validation - RPKI 1. Define a config format for Contact IP and ASID. 2. Each participant publishes their config in the RPKI database. 3. All participants sync the RPKI database as usual. - IPSEC 4. Each participant connects to all the other participants by IKE. 5. Data plane communicates with IPsec encapsulation. - COST: O(N²) IPsec associations with O(N) human work. - AOB + Open Mic (5 min) - 沒有人提出其他要討論的問題 ## 議題的挑戰與未來展望 IP Security Maintenance and Extensions (IPsecME) 工作組在IETF 118會議上討論的多個技術挑戰和相關議題。其中一項主要挑戰是針對DH with IKEv2和rekeys的問題,尤其是關於Child DH組和PARENT DH的協商不一致的情況。這引發了對安全協商和協商失敗的標準化和改進的討論。 另一方面,會議提到的BEET模式的討論顯示了在多連接網絡環境下使用IPsec的挑戰。這包括在航空領域中實際應用BEET,以處理來自多個網絡路徑的相同封包。該議題將可能需要制定相應的標準,以確保BEET模式的有效且安全的部署,並將其整合到IKEv2協商中。 Esp尾部的調整引發了有關安全性和性能之間的權衡的爭議,特別是在ICV檢查之前允許封包轉發的情況下。這反映了在實現性能優化時必須仔細平衡安全性和風險的挑戰。 未來展望包括繼續解決這些挑戰,特別是關於DH with IKEv2和rekeys的協商問題,以及確保新的技術和模式,如BEET,能夠得到標準化並被廣泛應用。此外,會議中提到的對Esp尾部的調整和其他性能優化可能需要更深入的分析和研究,以確保安全性不受影響。總結來說,IPsecME工作組面臨著在不同層面解決安全性、性能和標準化挑戰的任務。 ## 是否在會議中協作共筆或是使用Zulip實際參與討論?若有可分享自己貢獻的內容 沒有。但是有看著他們寫共筆,也有在Zulip裡面看他們的訊息,完全跟不上他們的對話。 ## 對於Datatracker的哪些工具覺得有幫助?哪些工具需要再改進? 都很有幫助。HedgeDoc、Zulip、Meetecho這些工具我都覺得很有幫助,之前有用過HackMD所以覺得HedgeDoc也很好用(甚至比免費版的HackMD好用),Zulip跟Discord很像也不錯,Meetecho真是我用過最好用的會議軟體。 ## 之前有參加過IETF嗎?會有興趣下次再參加嗎? 之前沒參加過IETF的會議。下次應該不會再參加,因為都聽不懂,不過如果有免費T-shirt應該就會參加。 ## 多益成績?對於會議使用英文,聽得懂的程度(1~10分 英文每個單字幾乎都聽得懂,但是合在一起就聽不懂了,我對這方面的技術都不懂。。。 多益880,但是不搭配會議記錄還是很難理解他們在講什麼,可能是太久沒用英文加上討論內容太技術性了。 ## 對於參加IETF meeting有什麼收穫? 我覺得IETF做事很嚴謹,規劃很完善,只是看著也學到很多。他們也很會利用工具,我了解了很多好用的工具。而且這場會議非常準時的結束了,誤差不超過五分鐘,我覺得很驚訝,我在時間規劃這塊也學到很多。 資源維護的蠻好的,有什麼訊息可以查閱,在 [Working Group](https://datatracker.ietf.org/wg/ipsecme/about/) 的網頁上都一目瞭然,內容也非常豐富,包含相關文件、會議歷史、甚至是自己的維基。考慮到這是一個從1990年代就開始運作的WG,能把這麼多文件分門別類整理好實在不容易。 ## 對IETF meeting的其他建議? 我覺得很好,各方面都做得很好,我學到很多。