1 / 13

Softwire Security Analysis and Guidance

This document provides a security analysis for softwire deployments, identifying threats and offering guidance for protection. It accompanies the framework document submitted to IESG.

hnadeau
Download Presentation

Softwire Security Analysis and Guidance

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 Analysis and Guidance Shu Yamamoto Carl Williams Florent Parent Hidetoshi Yokota draft-ietf-softwire-security-requirements-00.txt 1

  2. Purpose • Why we are creating a security analysis document • Identify security threats for softwire deployments • To provide the guidance for softwire security protection • This document will provide necessary security analysis for softwire to the IESG. It is expected that this document will accompany the framework document when it is submitted to the IESG.

  3. Current Document • Published 00 version • Doing this work early will help • Focus on L2TPv2 as phase1 softwire protocol. • Discussion on L2TPv3 based softwire is open. • Security requirement for Mesh is included in next version. • 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.

  4. Softwire Model Assumption for Hub & Spokes • Softwire is initiated from user side where SI resides. • Voluntary tunnel mode • L2TPv2 is assumed as Softwire protocol.(Phase 1) • Both LAC and PPP endpoint reside in SI. • Both L2TP and PPP are initiated from SI. • Authentication • “Customer” authentication must be supported. • Mutual authentication in some scenarios • Authentication can be turned off in some scenarios • Softwire is integrated with commonly deployed AAA solution for user authentication as well as machine. • Roaming support. • Stable IPv6 prefix possible • depends on service scenario at visited domain.

  5. Hub & Spokes Trust Relationship (Normal) IPv6 (or IPv4) AAAh Softwire Concentrator case 1 Trust Softwire Initiator Home domain

  6. Hub & Spokes Trust Relationship (Nomadic) IPv6 (or IPv4) IPv6 (or IPv4) AAAh AAAv Proxy Broker Trust Softwire Concentrator Softwire Concentrator case 3 (temporal address) case 1 case 2 (stable address) Softwire Initiator Softwire Initiator Visited domain Home domain

  7. Security ThreatAnalysis • When softwire traverses the public networks or third party network, the softwire control and data packets are vulnerable to attack. • The threat analysis is required to the softwire encapsulation method used to transport the payload and other protocols used for configuration. • Reference to related threat analysis documents • L2TP using IPsec (RFC3193) • PANA (RFC4016) • NSIS (RFC4081) • Others

  8. No new security risks Discovery process not secure Mutual authentication Protect messages between SI and SC Eavesdropping Spoofing Replay Service theft Automatic key management Softwire Security Considerations

  9. An adversary may try to discover user identities by snooping data packets. Provide confidentiality for data plane An adversary may try to modify packets. Provide integrity for control plane and data plane An adversary may try to hijack the softwire tunnel. Provide proper authentication and integrity An adversary can launch denial of service attacks by terminating softwire created tunnels. Measures such as ingress filtering may mitigate An adversary may impersonate the softwire concentrator to intercept traffic . (“rogue” softwire concentrator) Provide mutual authentication 6. Non-authenticated mode should be used in the managed network only. Security Threat Analysis and Mitigation

  10. The softwire control and/or data plane must be able to provide full payload security when desired. RFC3193 shows the usage of IPsec for L2TPv2 to provide tunnel authentication, privacy protection, integrity checking and replay protection. RFC3193 is applied in softwire model context (H&S) Softwire also requires NAT-traversal (Not covered in RFC3193). UDP encapsulation of IPsec ESP packets and negotiation of NAT-traversal in IKE MUST be supported in order to support NAT traversal. Softwire Control and Data Plane Protection

  11. Authentication Softwire protocol MUST support customer authentication in the control plane. Authentication varies from non-authentication to mutual authentication between SI and SC. Authentication possible at different layers PPP CHAP authentication L2TPv2 CHAP-like authentication. IPsec authentication (pre-shared key, cerficates, and EAP exchange identity for IKEv2) Softwire Authentication

  12. IPsec Interoperability Nothing specific to softwire whereas the inter-operability is discussed in RFC3193. IPsec filtering related items L2TP spec allows ‘SC’ to use a new IP address when sending SCCRP. Softwire also allows this for load-balancing among SCs. IPsec SPD entries SPD examples in RFC3193 appendix A can be applied. IPv6 over IPv4 softwire with L2TPv2 example to be given. IPv4 over IPv6 softwire with L2TPv2 example to be given. Other Items

  13. Revise draft based on comments from WG Add security analysis for mesh model Track framework and solution documents for modifications that may impact the security analysis document Next Steps

More Related