Softwire Security Requirement Update

draft-ietf-softwire-security-requirements-02.txt

IETF Meeting, PragueMarch 19, 2007

Shu YamamotoCarl WilliamsFlorent ParentHidetoshi 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 RFC3193 + 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

AF(i)-access

AF(i)-access

iBGP

iBGP

iBGP

PE

PE

PEtrusted each other

Case1 : PE-based/Inter AS

AF(j)-transit core

AS-1

AF(i)-access

AF(i)-access

AF(i)-access

iBGP

iBGP

iBGP

PE

PE

PE

AS-2

AS-3

AS-4eBGP

eBGP

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

AF(i)-access

AF(i)-access

iBGP

iBGP

iBGP

PEPE

PE

CE

CE

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