View
226
Download
0
Category
Tags:
Preview:
Citation preview
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?
Recommended