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. PPP Authentication (CHAP)
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 SC
Softwire
Host
ISP Network
AF(j)
CPE
User’ Home
Access Network
DoS
TRUSTED
PPP Encryption (ECP)
Voluntary Tunnel
Authentication can be turned off when already authenticated by other means.

4. 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 SC SI
Softwire
User
Host
ISP Network
Public Facilities
DoS
Snoop
Spoof
Replay
Modification Deletion
Rogue SC 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.
For non-trusted network
Control
Data
Integrity
Must
Replay
Confidentiality
Should
RFC3193: for Confidentiality, ‘Should’ for Control and ‘May’ for Data.

7. Applying IPsec in Hub&Spokes Scenario
IPv6
Applying IPsec in Hub&Spokes Scenario
AAA SC SI
Softwire
(PPP/L2TPv2/UDP/IPv4)
User
Host
ISP Network
ESP (transport mode)
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.

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

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

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

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

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

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.)
IPsec Authentication
To address that Group Shared key should not be used.
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.)
TCP MD5
TCP MD5 does not protect against so security attacks described in the document. Need more proper description for TCP MD5.
IPsec
Use of AH should be dropped. AH does not work for NAT traversal.
Should mention IKEv2 instead of IKEv1
Secure BGP
Typo