???? KDD???

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

8
Softwire Security Considerations

1. No new security risks
2. Discovery process not secure
3. Mutual authentication
4. Protect messages between SI and SC
5. Eavesdropping
6. Spoofing
7. Replay
8. Service theft
9. Automatic key management

9
Security Threat Analysis and Mitigation

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

10
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
  (HS)
• 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.

11
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)

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

13
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