Softwire Security Update Shu Yamamoto Carl Williams Florent

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

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. 2

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

Hub & Spokes Security Model (Non-Trusted) l Mutual Authentication MUST be used. l. PPP Authentication: no perpacket authentication, integrity nor replay protection l. IPsec authentication MUST be used. RFC 3193 Service Theft Non-TRUSTED L 2 TPv 2, PPP AAA SC Host SI AF(i) Softwire User Public Facilities ISP Network Do. S Rogue SC PPP Encryption (ECP): No key management 4 SC MITM BLH Snoop Spoof Replay Modification Deletion

Softwire Authentication Mechanism l PPP Authentication – Mutual authentication using CHAP – No per-packet authentication, no integrity, no replay protection l L 2 TPv 2 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 IKEv 2 ) – NAT-traversal in IKE 5

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 Control Data Integrity Must Replay Must Confidentiality Must Should RFC 3193: for Confidentiality, ‘Should’ for Control and ‘May’ for Data. 6

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

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

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

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

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

Security Protection AF(i) CE Static Route or Routing Protocol AF(i) CE TCP MD 5 IPsec S-BGP, so. BGP, ps. BGP Route Reflector BGP Update CE P AF(j) Backbone PE CE AF(i) CE PE AFBR-N AF(i) 12 P AF(i) AFBR-1 P IPsec CE Static Routing Packet Filtering CE AF(i) P PE AFBR-2 PE CE AF(i)

Softwire Mesh Security Protection l Control Plane Protection – TDP MD 5 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, so. BGP, and ps. BGP (Byzantine attacks) l Data Plane Protection – IPsec Encapsulation To support replay protection, integrity, and confidentiality ESP, IKE – Access Control Techniques 13

TCP MD 5 and IPsec for MP-BGP UPDATE l TCP MD 5 (RFC 2385) – 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. 14

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 phase 1 and ID) – Selectors – SPD – Proposed IPsec Tunnel Information TLV is enough? (only IKE identifier) 15

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

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 IKEv 2 description 17

Comments from Tero Kivinen (cont. ) • 3. 5. 2. 3 IPsec Authentication – To address that Group Shared key should not be used. • 3. 5. 5. 1 IPv 6 over IPv 4 Softwire with L 2 TPv 2 example – Comments on PDS table. Need more work. • 4. 1 Deployment Scenarios – Add more words • 4. 3 Softwire Threat Scenarios – Need some more explanation • 4. 5. 1 Security Protection mechanism for Control Plane – TCP MD 5 should not be mandated. IPsec Should be. 18

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