Softwire Security Update Shu Yamamoto Carl Williams Florent Parent Hidetoshi Yokota 67 IETF, San Diego

2 Document Status l Published -01 version – Revised “Hubs and Spokes” security Security description in framework document is added. Modification with comments at Interim Meeting. – Security for Mesh solution is added. l Subject to Framework Document – This work will keep track with the framework document. – This document will change over time subject to change of framework document.

3 Hub & Spokes Security Model (Trusted) CPE Softwire HostUser’ Home ISP Network Access Network AF(i) SC SI PPP/L2TP/UDP/IP AAA Authentication can be turned off when already authenticated by other means. PPP Authentication (CHAP) DoS TRUSTED AF(i,j) AF(i) AF(j) Mutual Authentication SHOULD be offered. (optionally one side) PPP Encryption (ECP) Voluntary Tunnel

4 Hub & Spokes Security Model (Non-Trusted) Softwire Host User ISP Network AF(i) SC SI L2TPv2, PPP AAA IPsec authentication MUST be used. Snoop Spoof Replay Modification Deletion DoS SC MITM BLH Rogue SC Public Facilities Service Theft Non-TRUSTED PPP Authentication: no per- packet authentication, integrity nor replay protection PPP Encryption (ECP): No key management RFC3193 Mutual Authentication MUST be used.

5 Softwire Authentication Mechanism l PPP Authentication – Mutual authentication using CHAP – No per-packet authentication, no integrity, no replay protection l L2TPv2 Authentication – Optional CHAP-like authentication – Same security verunerability as PPP l IPsec Authentication – MUST be used in non-trusted, public IP network – IKE must be supported. – Selection of Key management mechanism depends on deployment scenario (shared secret, certificate and EAP exchange identity for IKEv2 ) – NAT-traversal in IKE

6 Control and Data Plane Protection l IPsec can provide the necessary security mechanisms l “Full payload security” on control and data plane when required. – For non-trusted network ControlData IntegrityMust ReplayMust ConfidentialityMustShould RFC3193: for Confidentiality, ‘Should’ for Control and ‘May’ for Data.

7 Applying IPsec in Hub&Spokes Scenario Softwire Host User ISP Network IPv6 SC SI (PPP/L2TPv2/UDP/IPv4) AAA ESP (transport mode) l L2TPv2 and IPsec filter guidelines described in RFC3193 in case where the SC chooses a new IP address/port number: load-balancing l Use RFC3193 IPsec filter details (section 4) l SC and SI must have IPsec security policy filters pre-configured.

8 IPsec Security Policy example Softwire User AF(j) SC SI (PPP/L2TPv2/UDP/AF(i)) ESP (transport mode) src dst Protocol Action SI SC ESP BYPASS SI SC IKE BYPASS SI SC UDP, src 1701, dst 1701 PROTECT(ESP,transport) SC SI UDP, src *, dst 1701 PROTECT(ESP,transport) src dst Protocol Action * SC ESP BYPASS * SC IKE BYPASS * SC UDP, src *, dst 1701 PROTECT(ESP,transport)

9 Hub & Spokes Non-Authenticated Mode Softwire Host User ISP Network (Visited) AF(i) SC SI L2TPv2, PPP Non-Authentication Service Snoop Spoof Replay Modification Deletion SC MITM BLH Rogue SC Public Facilities Service Theft Non-TRUSTED Ingress Filter Anonymous Connection

10 Hub & Spokes Security Model (Visited) Softwire Host User ISP Network (Visited) AF(i) SC SI L2TPv2, PPP AAA Authentication Snoop Spoof Replay Modification Deletion SC MITM BLH Rogue SC Public Facilities Service Theft Non-TRUSTED Host ISP Network (Home) SC AAA Roaming Agreement

11 Mesh Security Model P CE PPP AFBR-1 AFBR-2 AFBR-N AF(j) Backbone AF(i) Route Reflector BGP Update DoS Intrusion Attack on Data Plane Attack on Control Plane PE Static Route or Routing Protocol PE

12 Security Protection P CE PPP AFBR-1 AFBR-2 AFBR-N AF(j) Backbone AF(i) BGP Update PE Static Routing Packet Filtering IPsec TCP MD5 IPsec S-BGP, soBGP, psBGP Static Route or Routing Protocol Route Reflector PE

13 Softwire Mesh Security Protection l Control Plane Protection – TDP MD5 MUST be supported Peer-peer based authentication Replay protection is not enough No protection for confidentiality – IPsec ESP provide confidentiality as well as integrity and authentication. IKE must be supported for replay protection – S-BGP, soBGP, and psBGP (Byzantine attacks) l Data Plane Protection – IPsec Encapsulation To support replay protection, integrity, and confidentiality ESP, IKE – Access Control Techniques

14 TCP MD5 and IPsec for MP-BGP UPDATE l TCP MD5 (RFC2385) – Offering Authentication and integrity on a point-to-point basis – Protection from spoofing attacks and connection hijacking – But not for eavesdropping and weak against replay attacks – Lack of an automated key management l IPsec – ESP protocol offers authentication, data integrity, and anti-replay between BGP speakers (i.e. AFBRs) – IKE protocol supported for automated key management – PKI can be used when available. – draft-bellovin-useipsec-05.txt provides guidelines for mandating the use of IPsec.

15 IPsec Softwire Mesh (Data Plane) l Encapsulation – BGP Tunnel SAFI provides Softwire mesh encapsulation attributes. – IPsec encapsulation is defined in Tunnel SAFI attributes. l IPsec Parameters – ESP (with or without encryption) – Transport/Tunnel Mode – Automated Key Management (IKE phase1 and ID) – Selectors – SPD – Proposed IPsec Tunnel Information TLV is enough? (only IKE identifier)

16 Next Steps To work with security liaison for the review of the document. To continue to track the framework document update.

17 Comments from Tero Kivinen 1. Introduction –Needs more explanation 3.1 H&S deployment Scenario –Something missing in description 3.3 Softwire Security Threat Scenarios –Add more other protocol 3.4 Softwire Security Guidelines –Editorial –Need correction of IKE description 3.5 Guidelines for Usage of Security Protection Mechanism –Need for IKEv2 description

18 Comments from Tero Kivinen (cont.) IPsec Authentication –To address that Group Shared key should not be used IPv6 over IPv4 Softwire with L2TPv2 example –Comments on PDS table. Need more work. 4.1 Deployment Scenarios –Add more words 4.3 Softwire Threat Scenarios –Need some more explanation Security Protection mechanism for Control Plane –TCP MD5 should not be mandated. IPsec Should be.

19 Comments from Tero Kivinen (cont.) TCP MD5 –TCP MD5 does not protect against so security attacks described in the document. Need more proper description for TCP MD IPsec –Use of AH should be dropped. AH does not work for NAT traversal. –Should mention IKEv2 instead of IKEv Secure BGP –Typo