Dynamic Virtual Networks (DVNE)

Margaret Wasserman & Paddy Nallur

November 11, 2010

IETF 79 -- Beijing, China

Two Drafts

• DVNE Framework– https://datatracker.ietf.org/doc/draft-mrw-dvne-fw/– Explains how Dynamic Virtual Networks are

constructed

• DVNE Protocol– https://datatracker.ietf.org/doc/draft-mrw-dvne-prot/– Describes a provisioning protocol to dynamically

provision a Dynamic Virtual Networks

Static Virtual Networks

Internet

B2

A1

Internet

NAT

B1A2

A4

A3B3

CGN

B4NAT

Issues to Address

• Node-to-Node Virtual Networks– Connectivity can be hard to establish due to NATs, IPv4-to-

IPv6 coexistence technologies, firewalls, etc.– Large Virtual Networks are unmanageable due to need to

configure virtual network parameters on every node.• Remote endpoint addresses, credentials, etc.

– Each node maintains state for every other node in the network, even if they never communicate

• Site-to-Site Virtual Networks– No consistent end-to-end security – Security depends on physical topology

• No support for flexible, centralized administration and provisioning

Functional Elements

B2

DVNE Mediator

VN Node

VN Node

VN Node

Edge Network

Basic Operation of Mediator

• Client desires DVNE connection to another host in the VN, asks mediator

• Mediator authenticates client• Mediator provisions both end of the connection

– Local IP addrss, address list for peer, STUN server address, credentials for secure tunnel, etc.

• VPN connection is established by endpoints– Using IPsec tunnel or DTLS– May use ICE, STUN or other mechanisms as

needed to establish connectivity

Dynamic, On-Demand Connection

B2

DVNE Mediator

Node B

Node A

VN Node

Edge Network

- Node A requests connection to Node B- Mediator provisions Node A & Node B- Secure connection from Node A to Node B

Dynamic Virtual Network

A1

Internet

NAT

B1A2

A4

A3B3

CGN

B4NAT

B2

Current IETF Solutions Used

• Various VPN/secure tunnel solutions– Such as IPsec or DTLS

• TLS for authentication• ICE/STUN for NAT traversal

• The DVNE protocol does not replace these technologies, it provisions nodes with the information to use them

Missing Piece

• IETF has no generic service provisioning protocol to use for Client-to-Mediator communication

• Existing management protocols have different model– “Configure yourself”, rather than “provision me”– No ability to trigger provisioning of service across

multiple nodes

• Existing data models (MIBs, Yang modules) could be used to hold data

Status of DVNE Work

• Current work focuses on a DVNE protocol for network authentication and DVNE service provisioning and virtual network set-up

• Work underway on national Standard in China for DVNE Framework– Combined work of Huawei Symantec, ZTE, and

China Mobile

• Prototype code up and running

Specific vs. General in IETF

• Specific need for a Dynamic Virtual Network provisioning protocol

• IETF may have more general need for a generic Service Provisioning protocol that could be applied to this space and others.

• Which should we pursue in the IETF?

Questions

• Should we work on this topic in the IETF?• Should we pursue a specific or general

solution?– Specific: DVNE protocol to provision VNs– Generic: Generic service provisioning protocol,

PLUS data model for provisioning VNs.

• Should we do the work here in the Ops Area WG? In separate Ops/NM WG? Elsewhere?