1 / 19

Softwire Security Update

This document describes the security framework for the "Hubs and Spokes" model in Softwire networks. It includes updates on authentication, encryption, access control, and protection against various attacks.

richardv
Download Presentation

Softwire Security Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Document Status • 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. • 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. SC Hub & Spokes Security Model (Trusted) AF(i) • Mutual Authentication SHOULD be offered. (optionally one side) PPP Authentication (CHAP) AF(i,j) AF(i) AAA SI PPP/L2TP/UDP/IP Softwire AF(j) Host User’ Home ISP Network CPE Access Network DoS TRUSTED PPP Encryption (ECP) Voluntary Tunnel • Authentication can be turned off when already authenticated by other means.

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

  5. Softwire Authentication Mechanism • PPP Authentication • Mutual authentication using CHAP • No per-packet authentication, no integrity, no replay protection • L2TPv2 Authentication • Optional CHAP-like authentication • Same security verunerability as PPP • 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 • IPsec can provide the necessary security mechanisms • “Full payload security” on control and data plane when required. • Fornon-trusted network RFC3193: for Confidentiality, ‘Should’ for Control and ‘May’ for Data.

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

  8. AF(j) SC IPsec Security Policy example SI (PPP/L2TPv2/UDP/AF(i)) Softwire User ESP (transport mode) src dst Protocol Action --- --- -------- -------- * SC ESP BYPASS * SC IKE BYPASS * SC UDP, src *, dst 1701 PROTECT(ESP,transport) 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)

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

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

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

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

  13. Softwire Mesh Security Protection • 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) • 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 • 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 • 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) • Encapsulation • BGP Tunnel SAFI provides Softwire mesh encapsulation attributes. • IPsec encapsulation is defined in Tunnel SAFI attributes. • 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.) • 3. 5.2.3 IPsec Authentication • To address that Group Shared key should not be used. • 3.5.5.1 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 • 4.5.1 Security Protection mechanism for Control Plane • TCP MD5 should not be mandated. IPsec Should be.

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

More Related