1. Softwire Security Requirement draft-ietf-softwire-security-requirements-03.txt Softwires WG IETF#69, Chicago 25 th July 2007 Shu Yamamoto Carl Williams Florent Parent Hidetoshi Yokota

2. Updates from Previous Version Clarification of IPsec mandate case for H&S Use RFC4301 IPsec architecture IKEv2/IPsec applied to L2TPv2 Mesh description change

3. RFC4301 Security Architecture –IKEv2 supersedes IKEv1 for KEY/SA management protocol Security Protocol –Per RFC4301, IPsec implementations MUST support ESP and MAY support AH. But no support of NAT-T for AH. IPsec inter-operability with L2TPv2 –If a SC (responder) changes it IP address (e.g., for load- balancing), the SC MUST send a StopCCN according to RFC3193, section 4. –A new IKE_SA and CHILD_SA is established by deleting the previous SA. Hubs & Spokes

4. Inter-Operability |------->| IKE_SA_INIT and IKE_AUTH to protect Initial SCCRQ |------->| SCCRQ(Fixed IP address, Dynamic Initiator Port) |<-------| STOPCCN (SC chooses new IP address) |------->| New IKE_SA_INIT and IKE_AUTH to protect New SCCRQ |------->| SCCRQ (SCCRQ to SC’s new IP address) |<-------| CREATE_CHILD_SA to change port number by SC |<-------| SCCRP (SC chooses new port number) |------->| SCCN(L2TP Tunnel Establishment completes) SI SC

5. IPsec Filtering –Based on RFC4301, SPD entries examples are provided. –Use of Peer authentication database (PAD), “populate from packet” (PFP) flag are also provided. –SPD examples for IKEv1 are moved to Appendix. Hubs & Spokes

6. IKEv2 Exchanges for L2TPv2 Initiator (SI)Responder (SC) ---------------------------------------------- HDR, SAi1, KEi, Ni   HDR, SAr1, KEr, Nr HDR, SK{IDi, CERT, AUTH, [IDr], SAi2, TSi, TSr}   HDR, SK{IDr, CERT, AUTH, SAr2, TSi, TSr}

7. L2TPv2 Protection Diagram PROTECT SPD-S SPD-O IPsec SAD ESP IKE IKEv2 L2TPv2 (ESP, Transport mode) Protected L2TPv2 SPD-I PROTECT BYPASS kernel PAD user

8. SI SPD Entry SI SPD entry for L2TPv2 protection –IP: Local = IPv4-SI Remote= IPv4-SC –Protocol = UDP/L2TPv2 –Port: Local = ANY (PFP=1) Remote = 1701 –Disposition = ESP transport mode Outgoing L2TPv2 traffic between SI and SC is protected by SPD(-S) entry. To support multiple tunnels, port number will be specified by using PFP (populate from packet) flag.

9. SC SPD Entry SC SPD entry for L2TPv2 protection –IP: Local = IPv4-SC Remote= ANY (PFP=1) –Protocol = UDP/L2TPv2 –Port: Local = 1701 Remote = ANY (PFP=1) –Disposition = ESP transport mode Incoming protected L2TPv2 traffic between SI and SC is examined by SPD(-S) entry. Remote node (SI) address (range) and port number (range) can be specified by PFP for SAD to be applied.

10. IKEv2 NAT-Traversal After NAT detection Normal IKEv2 After NAT detection Normal ESP IPUDP(500)IKEv2DATA IP Non-ESPIKEv2DATAUDP(4500) IP ESPDATA ESP ICV IP ESPDATA ESP ICV UDP(4500) IP NAT-T is integrated in IKEv2 exchanges

11. NAT Traversal of Protected L2TPv2 Packet L2TPv2 with ESP L2TPv2 After NAT detection Normal ESP PPP MTU should be adapted to avoid fragmentation. Optimization of encapsulation: L2TP over IP? Next phase using L2TPv3? IPUDP(1701)L2TPv2PPPDATA IPUDP(1701)L2TPv2PPPDATA ESP IPPayload ESP ESP ICV IPPayload ESP ESP ICV UDP(4500) IP UDP(1701) L2TPv2PPPDATA IP

12. Mesh Solution Description Change to general (high level) description To state mesh solution architecture and trust model for basic architecture To discuss potential security attacks for data plane and control plane based on RFC4111 and RFC4272, respectively. To provide minimum security protection implementation requirement based on Softwire problem statement and guidance of usages which depends on operators, network users, deployment scenario, etc.

13. Mesh Solution Security Summary Control Plane Security –Problem Statement: MUST be possible to protect from modification and spoofing. –This document: MUST support authentication (TCP MD5). MAY be turned off by transit core provider. But TCP-MD5 inadequate (from security review) Support of Key Management Protocol depends on Operation requirement Data Plane –Problem statement: (mesh) softwire solution must support IPsec. –This document: MUST support IPsec encapsulation for secure transport and recommend to use access control.

14. Next Step for Mesh Security Draft -03 still contains security protection mechanisms for control and data plane Security for mesh solution is now part of the mesh framework document. Need new version of this draft to reflect this change.

15. Next Steps Feedback from latest version –Any comment and correction are appreciated. Hub and spokes security –Received feedback from Francis Dupont. Changes in SPD required. Mesh security –Change to general description only –Refer to mesh framework document for security protection mechanisms Moving forward –Discuss on ML –Finalize current document