Softwire Security Requirement Update draft-ietf-softwire-security-requirements-02.txt

1. Softwire Security Requirement Updatedraft-ietf-softwire-security-requirements-02.txt Shu Yamamoto Carl Williams Florent Parent Hidetoshi Yokota IETF Meeting, Prague March 19, 2007

2. Status • Rev-02 is created incorporating comments on Rev-01 by Security Expert • Changed to IKEv2 centric description instead of IKEv1 for IPsec SA establishment

3. Mailing list comments Background softwire problem statement draft: "The goal of this effort is to reuse or extending existing technology. … , deployed technology must be very strongly considered in our solution selection.” Hub and spokes phase 0 is to use L2TPv2. Deployed clients that support L2TPv2 today likely support IKEv1 for securing L2TPv2 (RFC3193, Securing L2TP using IPsec). NAT-traversal for IKE and ESP is also deployed today in recent OS. Question on mailing list: IKEv1, apply RFC3193 + NAT traversal? Recommend IKEv2? Got 4 comments, all in favor in using IKEv2

4. Hubs & Spokes Change(1) • Review of Requirement Language • Requirement language for Softwire security protocol is made consistent with security description in “Softwire Problem Statement” • Softwire Security Threat Scenario (Section 3.3) • Clarification of softwire solution as a subset of L2TPv2 for softwire tunnel setup. • Add text for security protection mechanism in L2TPv2 tunnel setup procedure in Softwire context and address the security weakness • Without per-packet based authentication for PPP CHAP • Weak security solution of PPP ECP • No key management facilities for L2TPv2 CHAP option

5. Hubs & Spokes Change(2) • Softwire Security Guidelines (Section 3.4) • From generic descriptions in Rev-01 to more softwire specific descriptions based on the security threat analysis of Section 3.3 • Requirements for softwire security protocol are moved from Section 3.5 in Rev-01 to Section 3.4 in Rev-02 • Describe IPsec ESP in transport mode as Softwire security protocol to meet all requirements given in Section 3.4 • Change to Guidelines of IPsec usage (Section 3.5) • Change from security protection mechanism usage in Rev-01 to IPsec usage specific in Rev-02 • Change to IKEv2 centric description from IKE in general. e.g. new implementation SHOULD use IKEv2. • Revise SPD example per Security Expert comment • SPD for IKEv2 is not completed yet.

6. Hubs & Spokes Change(3) • Other Changes • Add warning text when non-authenticated connection or anonymous connection service is deployed. • Add the description of user authentication using EAP payload in case of IKEv2. • Address AAA involvement for authentication • Add description of the prohibition of group pre-shared keys

7. Mesh Change (1) • Mesh Deployment Scenario (Section 4.1) • Classification of two cases such as PE-based AFBR and provider provisioned CE-based AFBR. • Clarification of AS boundary for the discussion in Section 4.2. • Trust Relationship (Section 4.2) • Within a single autonomous system, nodes can trusteach other. But not necessarily for PE-CE link. • For CE model, trust relationship between CE-based AFBRs as well as between users in access islands and transit core provider are required. • CE-based AFBR should be provisioned by service provider.

8. Case1 : PE-based/Single AS single AS PE AF(i)-access iBGP PE AF(i)-access AF(j)-transit core iBGP iBGP AF(i)-access PE trusted each other • PE-based AFBR • PEs trust each other. Authentication may be turned off in some circumstances. (per Softwire Problem Statement) • When transit core includes non-trusted devices, security protection is required.

9. Case1 : PE-based/Inter AS AS-2 AS-1 PE AF(i)-access eBGP AS-4 iBGP PE eBGP AF(i)-access AF(j)-transit core iBGP AS-3 AF(i)-access iBGP eBGP trusted or non-trusted PE • PE-based AFBR • PE based AFBR trust each other. • PE-CE link may or may not be trusted. • Confidentiality may be needed when PE-CE link is not trusted. In this circumstance, cryptographic security protection such as IPsec ESP SHOULD be used.

10. Case2: CE based Single AS CE iBGP AF(i)-access PE CE PE AF(i)-access AF(j)-transit core iBGP PE AF(i)-access iBGP CE • CE-based AFBR • Dual stack processing is resided in CE of access networks. • Inter-CE BGP peering is used. • CEs MUST trust each other.

11. Mesh Change (2) • Applicability of Security Protection Mechanism (New Section 4.4) • Old Section 4.4 was Softwire Security Guideline. • Address security requirements for mesh solution described in Softwire Problem Statement. • Softwire mesh setup MUST support authentication • Transit core provider may turn it off in some circumstances • Softwire MUST support IPsec for data plane • Add description for encryption of PE-CE link referring to RFC4111 • Description of access control filtering moved from Section 4.5

12. Mesh Change (3) • Guidelines for Security Protection Mechanism Usage (Section 4.5) • Change text for TCP-MD5 usage for BGP peer at AFBR by stating that TCP-MD5 does not maintain a respectable level of security. • Change text of IPsec usage for BGP peer at AFBR describing the capability of confidentiality, integrity and authentication for BGP session. • Remove text regarding AH. • Address use of IKEv2 to support scalable key management. • Description of security protection mechanism for data plane requires more information on IPsec encapsulation from Softwire Mesh framework document which is in progress.

13. Next Steps • IKE2 description for Hubs & Spokes • Add SPD example for IKEv2 • More description of IKEv2 usage • Mesh description • Wait for Softwire Mesh Framework document • Moving forward • Finalize current document by adding above two items • Discuss changes on ML • Publish new version. • WGLC