---
# System prepended metadata

title: 計網 IETF 學習單

---


[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的其他建議？

我覺得很好，各方面都做得很好，我學到很多。




