Softwire%20Security%20Requirement%20draft-ietf-softwire-security-requirements-03.txt

1
Softwire Security Requirementdraft-ietf-softwire-
security-requirements-03.txt
Shu Yamamoto Carl Williams Florent
Parent Hidetoshi Yokota

• Softwires WG
• IETF69, Chicago
• 25th July 2007

2
Updates from Previous Version

• Clarification of IPsec mandate case for HS
• Use RFC4301 IPsec architecture
• IKEv2/IPsec applied to L2TPv2
• Mesh description change

3
Hubs Spokes

• RFC4301 Security Architecture
• IKEv2 supersedes IKEv1 for KEY/SA management
  protocol
• Security Protocol
• Per RFC4301, IPsec implementations MUST support
  ESP and MAY support AH. But no support of NAT-T
  for AH.
• IPsec inter-operability with L2TPv2
• If a SC (responder) changes it IP address (e.g.,
  for load-balancing), the SC MUST send a StopCCN
  according to RFC3193, section 4.
• A new IKE_SA and CHILD_SA is established by
  deleting the previous SA.

4
Inter-Operability
SI SC
-------gt IKE_SA_INIT and IKE_AUTH to protect
Initial SCCRQ -------gt SCCRQ (Fixed IP
address, Dynamic Initiator Port) lt-------
STOPCCN (SC chooses new IP address) -------gt
New IKE_SA_INIT and IKE_AUTH to protect New
SCCRQ -------gt SCCRQ (SCCRQ to SCs new IP
address) lt------- CREATE_CHILD_SA to change
port number by SC lt------- SCCRP (SC chooses
new port number) -------gt SCCN (L2TP Tunnel
Establishment completes)
5
Hubs Spokes

• IPsec Filtering
• Based on RFC4301, SPD entries examples are
  provided.
• Use of Peer authentication database (PAD),
  populate from packet (PFP) flag are also
  provided.
• SPD examples for IKEv1 are moved to Appendix.

6
IKEv2 Exchanges for L2TPv2
Initiator (SI) Responder (SC) ------------------
---------------------------- HDR, SAi1, KEi,
Ni ? ? HDR, SAr1, KEr, Nr HDR, SKIDi,
CERT, AUTH, IDr, SAi2, TSi, TSr ? ? HDR,
SKIDr, CERT, AUTH, SAr2, TSi, TSr
7
L2TPv2 Protection Diagram
IKEv2
PAD
L2TPv2
user
kernel
SPD-S
Protected L2TPv2
PROTECT
SPD-O
(ESP , Transport mode)
PROTECT
SPD-I
ESP IKE
BYPASS
SAD
IPsec
8
SI SPD Entry

• SI SPD entry for L2TPv2 protection
• IP Local IPv4-SI
• Remote IPv4-SC
• Protocol UDP/L2TPv2
• Port Local ANY (PFP1) Remote 1701
• Disposition ESP transport mode

Outgoing L2TPv2 traffic between SI and SC is
protected by SPD(-S) entry. To support multiple
tunnels, port number will be specified by using
PFP (populate from packet) flag.
9
SC SPD Entry

• SC SPD entry for L2TPv2 protection
• IP Local IPv4-SC
• Remote ANY (PFP1)
• Protocol UDP/L2TPv2
• Port Local 1701 Remote ANY (PFP1)
• Disposition ESP transport mode

Incoming protected L2TPv2 traffic between SI and
SC is examined by SPD(-S) entry. Remote node (SI)
address (range) and port number (range) can be
specified by PFP for SAD to be applied.
10
IKEv2 NAT-Traversal
NAT-T is integrated in IKEv2 exchanges
Normal IKEv2
IP
UDP(500)
IKEv2
DATA
IP
After NAT detection
IP
Non-ESP
IKEv2
DATA
UDP(4500)
IP
Normal ESP
ESP
DATA
IP
ESP ICV
After NAT detection
ESP
DATA
ESP ICV
IP
UDP(4500)
11
NAT Traversal of Protected L2TPv2 Packet
IP
UDP(1701)
L2TPv2
PPP
DATA
IP
L2TPv2
L2TPv2 with ESP
IP
UDP(1701)
L2TPv2
PPP
DATA
IP
ESP
IP
Payload
ESP
ESP ICV
Normal ESP
After NAT detection
IP
Payload
ESP
ESP ICV
UDP(4500)
IP
L2TPv2
PPP
DATA
UDP(1701)

• PPP MTU should be adapted to avoid fragmentation.

• Optimization of encapsulation L2TP over IP?
  Next phase using L2TPv3?

12
Mesh Solution Description

• Change to general (high level) description
• To state mesh solution architecture and trust
  model for basic architecture
• To discuss potential security attacks for data
  plane and control plane based on RFC4111 and
  RFC4272, respectively.
• To provide minimum security protection
  implementation requirement based on Softwire
  problem statement and guidance of usages which
  depends on operators, network users, deployment
  scenario, etc.

13
Mesh Solution Security Summary

• Control Plane Security
• Problem Statement MUST be possible to protect
  from modification and spoofing.
• This document MUST support authentication (TCP
  MD5). MAY be turned off by transit core provider.
• But TCP-MD5 inadequate (from security review)
• Support of Key Management Protocol depends on
  Operation requirement
• Data Plane
• Problem statement (mesh) softwire solution must
  support IPsec.
• This document MUST support IPsec encapsulation
  for secure transport and recommend to use access
  control.

14
Next Step for Mesh Security

• Draft -03 still contains security protection
  mechanisms for control and data plane
• Security for mesh solution is now part of the
  mesh framework document.
• Need new version of this draft to reflect this
  change.

15
Next Steps

• Feedback from latest version
• Any comment and correction are appreciated.
• Hub and spokes security
• Received feedback from Francis Dupont.
• Changes in SPD required.
• Mesh security
• Change to general description only
• Refer to mesh framework document for security
  protection mechanisms
• Moving forward
• Discuss on ML
• Finalize current document