Transcript Dynamic Virtual Networks

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
Internet
NA
T
A1
NAT
CGN
A4
A2
B1
B2
B3
A3
B4
Issues to Address
• Node-to-Node Virtual Networks
– Connectivity can be hard to establish due to NATs, IPv4-toIPv6 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
DVNE Mediator
VN Node
VN Node
B2
Edge Network
VN Node
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
DVNE Mediator
VN Node
Node B
B2
Edge Network
Node A
- Node A requests connection to Node B
- Mediator provisions Node A & Node B
- Secure connection from Node A to Node B
Dynamic Virtual Network
Internet
NAT
A1
NAT
CGN
A4
A2
B1
B2
B3
A3
B4
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?