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

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

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 RFC NAT traversal? –Recommend IKEv2? Got 4 comments, all in favor in using IKEv2

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

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. Hubs & Spokes Change(2)

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 Hubs & Spokes Change(3)

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 trust each 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.

Case1 : PE-based/Single AS 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. AF(j)-transit core single AS AF(i)- access iBGP PE trusted each other

Case1 : PE-based/Inter AS AF(j)-transit core AS-1 AF(i)- access iBGP PE AS-2 AS-3 AS-4 eBGP 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. trusted or non- trusted

Case2: CE based AF(j)-transit core Single AS AF(i)- access iBGP PE 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.

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

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.

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