Transcript PPT Version

Softwire Security Analysis
and Guidance
Shu Yamamoto
Carl Williams
Florent Parent
Hidetoshi Yokota
draft-ietf-softwire-security-requirements-00.txt
1
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.
2
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.
3
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.
4
Hub & Spokes Trust Relationship (Normal)
IPv6 (or IPv4)
AAAh
Softwire
Concentrator
case 1
Trust
Softwire
Initiator
Home domain
5
Hub & Spokes Trust Relationship (Nomadic)
IPv6 (or IPv4)
AAAh
Softwire
Concentrator
case 1
IPv6 (or IPv4)
AAAv
Trust
case 2
(stable address)
Softwire
Initiator
Home domain
Proxy Broker
Softwire
Concentrator
case 3
(temporal
address)
Softwire
Initiator
Visited domain
6
Security Threat Analysis
• 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
7
Softwire Security Considerations
1.
2.
3.
4.
5.
6.
7.
8.
9.
No new security risks
Discovery process not secure
Mutual authentication
Protect messages between SI and SC
Eavesdropping
Spoofing
Replay
Service theft
Automatic key management
8
Security Threat Analysis and Mitigation
1.
An adversary may try to discover user identities by snooping
data packets.
–
2.
An adversary may try to modify packets.
–
3.
Provide integrity for control plane and data plane
An adversary may try to hijack the softwire tunnel.
–
4.
Provide proper authentication and integrity
An adversary can launch denial of service attacks by
terminating softwire created tunnels.
–
5.
Measures such as ingress filtering may mitigate
An adversary may impersonate the softwire concentrator to
intercept traffic . (“rogue” softwire concentrator)
–
6.
Provide confidentiality for data plane
Provide mutual authentication
Non-authenticated mode should be used in the managed
network only.
9
Softwire Control and Data Plane Protection
• 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.
10
Softwire Authentication
• 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)
11
Other Items
• 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.
12
Next Steps
• 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
13