draft-ietf-i2nsf-gap-analysis-01.txt   draft-ietf-i2nsf-gap-analysis-02.txt 
I2NSF WG S. Hares I2NSF WG S. Hares
Internet-Draft R. Moskowitz Internet-Draft R. Moskowitz
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: October 6, 2016 D. Zhang Expires: January 21, 2017 D. Zhang
April 4, 2016 July 20, 2016
Analysis of Existing work for I2NSF Analysis of Existing work for I2NSF
draft-ietf-i2nsf-gap-analysis-01.txt draft-ietf-i2nsf-gap-analysis-02.txt
Abstract Abstract
This document analyzes the current state of the art for security This document analyzes the current state of the art for security
management devices and security devices technologies in industries management devices and security devices technologies in industries
and the existing IETF work/protocols that are relevant to the and the existing IETF work/protocols that are relevant to the
Interface to Network Security Function (I2NSF). The I2NSF focus is Interface to Network Security Function (I2NSF). The I2NSF focus is
to define data models and interfaces in order to control and monitor to define data models and interfaces in order to control and monitor
the physical and virtual aspects of network security functions. the physical and virtual aspects of network security functions.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2016. This Internet-Draft will expire on January 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is I2NSF . . . . . . . . . . . . . . . . . . . . . . 3 1.1. What is I2NSF . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Structure of this Document . . . . . . . . . . . . . . . 4 1.2. Structure of this Document . . . . . . . . . . . . . . . 4
1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5 1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5
1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5 1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5
1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5
2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6 2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6 2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9 2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9
2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 10
3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13 3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13
3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 15 3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 15
4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15 4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15
4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17 4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17
5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17 5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17
5.1. Overview of API for Security Group . . . . . . . . . . . 18 5.1. Overview of API for Security Group . . . . . . . . . . . 18
5.2. Overview of Firewall as a Service . . . . . . . . . . . . 18 5.2. Overview of Firewall as a Service . . . . . . . . . . . . 18
5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19 5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 2, line 44 skipping to change at page 2, line 44
6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22 6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22
6.1.4. Web Security (Web) . . . . . . . . . . . . . . . . . 23 6.1.4. Web Security (Web) . . . . . . . . . . . . . . . . . 23
6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24 6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24
6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25 6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25
6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26 6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26
6.1.8. Security Information and Event Management(SIEM) . . . 27 6.1.8. Security Information and Event Management(SIEM) . . . 27
6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28 6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28
6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29 6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29
6.1.11. Network Security Devices . . . . . . . . . . . . . . 30 6.1.11. Network Security Devices . . . . . . . . . . . . . . 30
6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31 6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31
7. In-depth Review of IETF protocols . . . . . . . . . . . . . . 31 7. IEEE security . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 31 7.1. Port-based Network Access Control [802.1X] . . . . . . . 31
7.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 32 7.2. MAC security (802.1AE) . . . . . . . . . . . . . . . . . 32
7.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 33 7.3. Secure Device Identity [802.1AR] . . . . . . . . . . . . 33
7.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. In-depth Review of IETF protocols . . . . . . . . . . . . . . 34
7.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 34
7.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 35 8.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 8.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This documents provides a gap analysis for I2NSF. This documents provides a gap analysis for I2NSF.
1.1. What is I2NSF 1.1. What is I2NSF
A Network Security Function (NSF) ensures integrity, confidentiality A Network Security Function (NSF) ensures integrity, confidentiality
and availability of network communications, detects unwanted and availability of network communications, detects unwanted
activity, and/or blocks out or at least mitigates the effects of activity, and/or blocks out or at least mitigates the effects of
skipping to change at page 31, line 41 skipping to change at page 31, line 41
6.2. I2NSF Gap Analysis 6.2. I2NSF Gap Analysis
The CSA Security as a Service (SaaS) document show clearly that there The CSA Security as a Service (SaaS) document show clearly that there
is a gap between the ability of the CSA SaaS devices to have a vendor is a gap between the ability of the CSA SaaS devices to have a vendor
neutral, inoperable protocol that allow the multiple of network neutral, inoperable protocol that allow the multiple of network
security devices to communicate passing provisioning and security devices to communicate passing provisioning and
informational data. Each of the 10 implementation agreements points informational data. Each of the 10 implementation agreements points
to this as a shortcoming. Standard I2NSF YANG models and an I2NSF to this as a shortcoming. Standard I2NSF YANG models and an I2NSF
protocol are needed according to the CSA SaaS documents. protocol are needed according to the CSA SaaS documents.
7. In-depth Review of IETF protocols 7. IEEE security
7.1. NETCONF and RESTCONF 7.1. Port-based Network Access Control [802.1X]
802.1x defines encapsulation of Extensible Authentication Protocol
(EAP) [RFC3748] over IEEE 802 (EAP over LAN, or EAPOL). It is widely
deployed on both wired and Wi-Fi Networks.
EAP provides support for security from passwords to challenge-
response tokens and public-key infrastructure certificates.
802.1 has three concepts:
o the supplicant - the user or client who wants to be authenticated
o authentication server - the server doing the authrentication (e.g.
radius server), and
o the authenticator - the device in-between authentication server
and supplicant (e.g. wireless Access Point (AP).
A normal sequence is below:
supplicant authenticator authentication server
=========== =================== ========================
<---- EAP-Request/Identity
EAP-Response/Identity---->
EAP-Response/Identity---gt;
<---------Challenge
<------Challenge
Challenge
response --------->
Challenge
Response --------->
Gap:
This basic service provides access, but today's access use cases are
more complex. IEEE 801.X has ben attched using the Man-in-the-middle
attacks. Another weakness of 802.1X is the speed of the EAP
protocols processing with the radius server.
Note: Editor - more is needed here
7.2. MAC security (802.1AE)
MACsec security secures a link rather than a conversation for 802.1
LANs (VLANs 802.1Q, Provider Bridges 802.1AD). MACsec counters the
802.1X man-in the middle attacks.
MACsec (in 802.1AE) provides MAC-layer encryption over wired networks
by using out-of-band methods for encryption keying. The MACsec Key
Agreement (MKA) Protocol provides the required session keys and
manages the required encryption keys. MKA and MACsec are implemented
after successful authentication using the 802.1x Extensible
Authentication Protocol (EAP) framework. Only hosts link which face
the network can be secured with MACSec. These links connect the host
to the network access devices.
Switch using MACsec accepts either MACsec or non-MACsec frames based
on policy set. The NSF controller can set within the switches
configuration whether MACSec frames are accepted. Accepted MACsec
frames are encrypted and protected with an integrity check value
(ICV). The switch after receiving frames from the client, decrypts
them and calculates the correct ICV by using session keys provided by
MKA. The switch compares that ICV to the ICV within the frame. If
they are not identical, the frame is dropped. The switch also
encrypts and adds an ICV to any frames sent over the secured port
(the access point used to provide the secure MAC service to a client)
using the current session key.
The MKA Protocol manages the encryption keys used by the underlying
MACsec protocol. The basic requirements of MKA are defined in
802.1x-REV. The MKA Protocol extends 802.1x to allow peer discovery
with confirmation of mutual authentication and sharing of MACsec
secret keys to protect data exchanged by the peers. MKA protocol ues
EAP-over-LAN (EAPOL) packet. EAP authentication produces a master
session key (MSK) shared by both partners in the data exchange.
Entering the EAP session ID generates a secure connectivity
association key name (CKN). Because the switch is the authenticator,
and the key serer, it can generating a random 128-bit secure
association key (SAK), which it sends it to the client partner. The
client is never a key server and can only interact with a single MKA
entity, the key server. After key derivation and generati
Gap Analysis:
I2NSF Devices must handle the existence of MSEC within the network.
7.3. Secure Device Identity [802.1AR]
802.1AR does the following:
Supports trail of trust from manufacturer to user, and
Defines how a Secure Device Identifier (DevId) may be
cryptographically bound to a device to support device identity
authentication.
DevIDs are composed of a secure device identifier secret and a
secure device identifier credential. These IDs can be controlled
by the product manufacturer (IDevID, an initially installed
identity) or by the end-user (LDevID, a subsequent locally
significant identity derived from the IDevID). DevIDs cannot be
be changed by the end-user.
One attack mitigation can be to disable support for DeVIDs or
limit to know DeVIDs.
GAP analysis:
I2NSF controllers need to support 802.1AR device management.
8. In-depth Review of IETF protocols
8.1. NETCONF and RESTCONF
The IETF NETCONF working group has developed the basics of the The IETF NETCONF working group has developed the basics of the
NETCONF protocol focusing on secure configuration and querying NETCONF protocol focusing on secure configuration and querying
operational state. The NETCONF protocol [RFC6241] may be run over operational state. The NETCONF protocol [RFC6241] may be run over
TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults
[RFC6243], handling events ([RFC5277] and basic notification [RFC6243], handling events ([RFC5277] and basic notification
[RFC6470], and filtering writes/reads based on network access control [RFC6470], and filtering writes/reads based on network access control
models (NACM, [RFC6536]). The NETCONF configuration must be models (NACM, [RFC6536]). The NETCONF configuration must be
committed to a configuration data store (denoted as config=TRUE). committed to a configuration data store (denoted as config=TRUE).
YANG models identify nodes within a configuration data store or an YANG models identify nodes within a configuration data store or an
skipping to change at page 32, line 44 skipping to change at page 35, line 17
o RESTCONF [I-D.ietf-netconf-restconf] o RESTCONF [I-D.ietf-netconf-restconf]
o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home] o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home]
o RESTCONF collection protocol o RESTCONF collection protocol
[I-D.ietf-netconf-restconf-collection] [I-D.ietf-netconf-restconf-collection]
o NETCONF Zero Touch Provisioning [I-D.ietf-netconf-zerotouch] o NETCONF Zero Touch Provisioning [I-D.ietf-netconf-zerotouch]
7.2. I2RS Protocol 8.2. I2RS Protocol
Based on input from the NETCONF working group, the I2RS working group Based on input from the NETCONF working group, the I2RS working group
decided to re-use the NETCONF or RESTCONF protocols and specify decided to re-use the NETCONF or RESTCONF protocols and specify
additions to these protocols rather than create yet another protocol additions to these protocols rather than create yet another protocol
(YAP). (YAP).
The required extensions for the I2RS protocol are in the following The required extensions for the I2RS protocol are in the following
drafts: drafts:
o [I-D.ietf-i2rs-ephemeral-state], o [I-D.ietf-i2rs-ephemeral-state],
skipping to change at page 33, line 22 skipping to change at page 35, line 41
o [I-D.ietf-i2rs-traceability] o [I-D.ietf-i2rs-traceability]
o [I-D.ietf-i2rs-protocol-security-requirements] o [I-D.ietf-i2rs-protocol-security-requirements]
At this time, NETCONF and RESTCONF cannot handle the ephemeral data At this time, NETCONF and RESTCONF cannot handle the ephemeral data
store proposed by I2RS, the publication and subscription store proposed by I2RS, the publication and subscription
requirements, the traceability, or the security requirements for the requirements, the traceability, or the security requirements for the
transport protocol and message integrity. transport protocol and message integrity.
7.3. NETMOD YANG modules 8.3. NETMOD YANG modules
NETMOD developed initial YANG models for interfaces [RFC7223]), IP NETMOD developed initial YANG models for interfaces [RFC7223]), IP
address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP
Systems ([RFC7317]) with system ID, system time management, DNS Systems ([RFC7317]) with system ID, system time management, DNS
resolver, Radius client, SSH, syslog resolver, Radius client, SSH, syslog
([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]), ([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]),
and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing
working group (rtgwg) has begun to examine policy for routing and working group (rtgwg) has begun to examine policy for routing and
tunnels. tunnels.
skipping to change at page 34, line 4 skipping to change at page 36, line 24
o L3VPN [I-D.li-bess-l3vpn-yang] and o L3VPN [I-D.li-bess-l3vpn-yang] and
[I-D.hu-bess-l2vpn-service-yang], [I-D.hu-bess-l2vpn-service-yang],
TEAS working group has proposed [I-D.ietf-teas-yang-te-topo], and TEAS working group has proposed [I-D.ietf-teas-yang-te-topo], and
[I-D.ietf-teas-yang-rsvp]. [I-D.ietf-teas-yang-rsvp].
MPLS/PCE/CCAMP groups have proposed the following Yang modules: MPLS/PCE/CCAMP groups have proposed the following Yang modules:
o [I-D.raza-mpls-ldp-mldp-yang] o [I-D.raza-mpls-ldp-mldp-yang]
o [I-D.saad-mpls-static-yang], o [I-D.saad-mpls-static-yang],
o [I-D.zheng-mpls-lsp-ping-yang-cfg], o [I-D.zheng-mpls-lsp-ping-yang-cfg],
o [I-D.pkd-pce-pcep-yang], and o [I-D.pkd-pce-pcep-yang], and
o [I-D.zhang-ccamp-transport-ctrlnorth-yang]. o [I-D.zhang-ccamp-transport-ctrlnorth-yang].
7.4. COPS 8.4. COPS
One early focus on flow filtering based on policy enforcement of One early focus on flow filtering based on policy enforcement of
traffic entering a network is the 1990s COPS [RFC2748] design (PEP traffic entering a network is the 1990s COPS [RFC2748] design (PEP
and PDP) as shown in Figure 11. The COPS policy decision points and PDP) as shown in Figure 11. The COPS policy decision points
(PDP) managed network-wide policy (e.g. ACLs) by installing this (PDP) managed network-wide policy (e.g. ACLs) by installing this
policy in policy enforcement points (PEPs) on the edge of the policy in policy enforcement points (PEPs) on the edge of the
network. These PEPs had firewall-like functions that control what network. These PEPs had firewall-like functions that control what
data flows into the network at a PEP point, and data flow out of a data flows into the network at a PEP point, and data flow out of a
network at a PEP. [RFC3084] describes COPS usages for policy network at a PEP. [RFC3084] describes COPS usages for policy
provisioning. provisioning.
skipping to change at page 35, line 5 skipping to change at page 37, line 34
Why I2NSF is Different from COPS Why I2NSF is Different from COPS
COPS was a protocol for policy related to Quality of Service (QoS) COPS was a protocol for policy related to Quality of Service (QoS)
and signaling protocols (e.g. RSVP) (security, flow, and others). and signaling protocols (e.g. RSVP) (security, flow, and others).
I2NSF creates a common protocol between security policy decision I2NSF creates a common protocol between security policy decision
points (SPDP) and security enforcement points (SEP). Today's points (SPDP) and security enforcement points (SEP). Today's
security devices currently only use proprietary protocols. security devices currently only use proprietary protocols.
Manufacturers would like a security specific policy enforcement Manufacturers would like a security specific policy enforcement
protocol rather than a generic policy protocol. protocol rather than a generic policy protocol.
7.5. PCP 8.5. PCP
As indicated by the name, the Port Control Protocol (PCP) enables an As indicated by the name, the Port Control Protocol (PCP) enables an
IPv4 or IPv6 host to flexibly manage the IP address and port mapping IPv4 or IPv6 host to flexibly manage the IP address and port mapping
information on Network Address Translators (NATs) or firewalls, to information on Network Address Translators (NATs) or firewalls, to
facilitate communication with remote hosts. facilitate communication with remote hosts.
PCP RFCs: PCP RFCs:
[RFC6887] [RFC6887]
skipping to change at page 35, line 31 skipping to change at page 38, line 12
[I-D.ietf-pcp-proxy] [I-D.ietf-pcp-proxy]
Why is I2NSF Different from PCP: Why is I2NSF Different from PCP:
Here are some aspects that I2NSF is different from PCP: Here are some aspects that I2NSF is different from PCP:
o PCP only supports management of port and address information o PCP only supports management of port and address information
rather than any other security functions rather than any other security functions
7.6. NSIS - Next Steps in Signaling 8.6. NSIS - Next Steps in Signaling
NSIS aims to standardize an IP signaling protocol (RSVP) along the NSIS aims to standardize an IP signaling protocol (RSVP) along the
data path for end points to request their unique QoS characteristics, data path for end points to request their unique QoS characteristics,
unique FW policies or NAT needs (RFC5973) that are different from the unique FW policies or NAT needs (RFC5973) that are different from the
FW/NAT original settings. The requests are communicated directly to FW/NAT original settings. The requests are communicated directly to
the FW/NAT devices. NSIS is like east-west protocols that require the FW/NAT devices. NSIS is like east-west protocols that require
all involved devices to fully comply to make it work. all involved devices to fully comply to make it work.
NSIS is path-coupled; it is possible to message every participating NSIS is path-coupled; it is possible to message every participating
device along a path without having to know its location, or its device along a path without having to know its location, or its
skipping to change at page 37, line 7 skipping to change at page 39, line 29
interoperable protocols that span controllers/routers, middle- interoperable protocols that span controllers/routers, middle-
boxes, and security end-systems. boxes, and security end-systems.
o IETF has a history of working on interoperable protocols or o IETF has a history of working on interoperable protocols or
virtualized network functions (L2VPN, L3VPN) that are deployed by virtualized network functions (L2VPN, L3VPN) that are deployed by
operators in large scale devices. IETF has a strong momentum to operators in large scale devices. IETF has a strong momentum to
create virtualized network functions (see SFC WG in routing) to be create virtualized network functions (see SFC WG in routing) to be
deployed in network boxes. [Note: We need to add SACM and others deployed in network boxes. [Note: We need to add SACM and others
here]. here].
8. IANA Considerations 9. IANA Considerations
No IANA considerations exist for this document. No IANA considerations exist for this document.
9. Security Considerations 10. Security Considerations
No security considerations are involved with a gap analysis. No security considerations are involved with a gap analysis.
10. Contributors 11. Contributors
The following people have contributed to this document: Hosnieh The following people have contributed to this document: Hosnieh
Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive
comments, great suggestions, and valuable insights on alternative comments, great suggestions, and valuable insights on alternative
views. views.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 12.2. Informative References
[I-D.brissette-bess-evpn-yang] [I-D.brissette-bess-evpn-yang]
Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh, Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh,
T., and I. Hussain, "Yang Data Model for EVPN", draft- T., and I. Hussain, "Yang Data Model for EVPN", draft-
brissette-bess-evpn-yang-01 (work in progress), December brissette-bess-evpn-yang-01 (work in progress), December
2015. 2015.
[I-D.hares-i2nsf-terminology] [I-D.hares-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., and L. Xia, "I2NSF Hares, S., Strassner, J., Lopez, D., and L. Xia, "I2NSF
Terminology", draft-hares-i2nsf-terminology-00 (work in Terminology", draft-hares-i2nsf-terminology-00 (work in
skipping to change at page 38, line 23 skipping to change at page 40, line 46
March 2016. March 2016.
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-11 (work in System", draft-ietf-i2rs-architecture-11 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-05 (work in Requirements", draft-ietf-i2rs-ephemeral-state-14 (work in
progress), March 2016. progress), July 2016.
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-10 (work in progress), February 2016. problem-statement-11 (work in progress), May 2016.
[I-D.ietf-i2rs-protocol-security-requirements] [I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security- Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-03 (work in progress), March 2016. requirements-06 (work in progress), May 2016.
[I-D.ietf-i2rs-pub-sub-requirements] [I-D.ietf-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-05 (work in progress), February 2016. requirements-09 (work in progress), May 2016.
[I-D.ietf-i2rs-rib-data-model] [I-D.ietf-i2rs-rib-data-model]
Wang, L., Ananthakrishnan, H., Chen, M., Wang, L., Ananthakrishnan, H., Chen, M.,
amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A
YANG Data Model for Routing Information Base (RIB)", YANG Data Model for Routing Information Base (RIB)",
draft-ietf-i2rs-rib-data-model-05 (work in progress), draft-ietf-i2rs-rib-data-model-06 (work in progress), July
March 2016. 2016.
[I-D.ietf-i2rs-rib-info-model] [I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Kini, S., and J. Medved, "Routing Information Bahadur, N., Kini, S., and J. Medved, "Routing Information
Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work
in progress), October 2015. in progress), July 2016.
[I-D.ietf-i2rs-traceability] [I-D.ietf-i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and the Routing System (I2RS) Traceability: Framework and
Information Model", draft-ietf-i2rs-traceability-07 (work Information Model", draft-ietf-i2rs-traceability-11 (work
in progress), February 2016. in progress), May 2016.
[I-D.ietf-i2rs-usecase-reqs-summary] [I-D.ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 Requirements", draft-ietf-i2rs-usecase-reqs-summary-01
(work in progress), May 2015. (work in progress), May 2015.
[I-D.ietf-i2rs-yang-l2-network-topology] [I-D.ietf-i2rs-yang-l2-network-topology]
Dong, J. and X. Wei, "A YANG Data Model for Layer-2 Dong, J. and X. Wei, "A YANG Data Model for Layer-2
Network Topologies", draft-ietf-i2rs-yang-l2-network- Network Topologies", draft-ietf-i2rs-yang-l2-network-
topology-02 (work in progress), December 2015. topology-03 (work in progress), July 2016.
[I-D.ietf-i2rs-yang-network-topo] [I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N.,
and H. Ananthakrishnan, "A Data Model for Network Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-02 (work in Topologies", draft-ietf-i2rs-yang-network-topo-04 (work in
progress), December 2015. progress), July 2016.
[I-D.ietf-idr-bgp-model] [I-D.ietf-idr-bgp-model]
Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K.,
Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. Bansal, D., Clemm, A., Zhdankin, A., Jethanandani, M., and
Liu, "BGP Model for Service Provider Networks", draft- X. Liu, "BGP Model for Service Provider Networks", draft-
ietf-idr-bgp-model-01 (work in progress), January 2016. ietf-idr-bgp-model-01 (work in progress), January 2016.
[I-D.ietf-isis-yang-isis-cfg] [I-D.ietf-isis-yang-isis-cfg]
Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.
Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- Lhotka, "YANG Data Model for ISIS protocol", draft-ietf-
isis-yang-isis-cfg-02 (work in progress), March 2015. isis-yang-isis-cfg-02 (work in progress), March 2015.
[I-D.ietf-l3sm-l3vpn-service-model] [I-D.ietf-l3sm-l3vpn-service-model]
Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K. Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K.
D'Souza, "YANG Data Model for L3VPN service delivery", D'Souza, "YANG Data Model for L3VPN service delivery",
skipping to change at page 41, line 32 skipping to change at page 44, line 14
[I-D.ietf-teas-yang-rsvp] [I-D.ietf-teas-yang-rsvp]
Beeram, V., Saad, T., Gandhi, R., Liu, X., Shah, H., Chen, Beeram, V., Saad, T., Gandhi, R., Liu, X., Shah, H., Chen,
X., Jones, R., and B. Wen, "A YANG Data Model for Resource X., Jones, R., and B. Wen, "A YANG Data Model for Resource
Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp-03 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp-03
(work in progress), March 2016. (work in progress), March 2016.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for TE Topologies", draft-ietf- O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
teas-yang-te-topo-04 (work in progress), March 2016. teas-yang-te-topo-05 (work in progress), July 2016.
[I-D.kini-i2rs-fb-rib-info-model] [I-D.kini-i2rs-fb-rib-info-model]
Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan,
R., Bogdanovic, D., and R. White, "Filter-Based RIB R., Bogdanovic, D., and R. White, "Filter-Based RIB
Information Model", draft-kini-i2rs-fb-rib-info-model-03 Information Model", draft-kini-i2rs-fb-rib-info-model-03
(work in progress), February 2016. (work in progress), February 2016.
[I-D.li-bess-l3vpn-yang] [I-D.li-bess-l3vpn-yang]
Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B.
Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess- Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess-
l3vpn-yang-00 (work in progress), October 2015. l3vpn-yang-00 (work in progress), October 2015.
[I-D.pkd-pce-pcep-yang] [I-D.pkd-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and j.
YANG Data Model for Path Computation Element jefftant@gmail.com, "A YANG Data Model for Path
Communications Protocol (PCEP)", draft-pkd-pce-pcep- Computation Element Communications Protocol (PCEP)",
yang-05 (work in progress), January 2016. draft-pkd-pce-pcep-yang-06 (work in progress), July 2016.
[I-D.raza-mpls-ldp-mldp-yang] [I-D.raza-mpls-ldp-mldp-yang]
Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H. Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H.
Shah, "YANG Data Model for MPLS LDP and mLDP", draft-raza- Shah, "YANG Data Model for MPLS LDP and mLDP", draft-raza-
mpls-ldp-mldp-yang-03 (work in progress), March 2016. mpls-ldp-mldp-yang-04 (work in progress), July 2016.
[I-D.saad-mpls-static-yang] [I-D.saad-mpls-static-yang]
Raza, K., Gandhi, R., Liu, X., Beeram, V., Saad, T., Chen, Saad, T., Raza, K., Gandhi, R., Liu, X., Beeram, V., Shah,
X., Jones, R., and B. Wen, "A YANG Data Model for MPLS H., Bryskin, I., Chen, X., Jones, R., and B. Wen, "A YANG
Base and Static LSPs", draft-saad-mpls-static-yang-02 Data Model for MPLS Static LSPs", draft-saad-mpls-static-
(work in progress), March 2016. yang-03 (work in progress), May 2016.
[I-D.shah-bess-l2vpn-yang] [I-D.shah-bess-l2vpn-yang]
Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z., Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z.,
Zhuang, S., Wang, H., Chen, I., Ahmed, S., Bocci, M., Zhuang, S., Wang, H., Chen, I., Ahmed, S., Bocci, M.,
Hardwick, J., Esale, S., Tiruveedhula, K., Singh, T., Hardwick, J., Esale, S., Tiruveedhula, K.,
Hussain, I., Wen, B., Walker, J., Delregno, N., Jalil, L., tsingh@juniper.net, t., Hussain, I., Wen, B., Walker, J.,
and M. Joecylyn, "YANG Data Model for MPLS-based L2VPN", Delregno, N., Jalil, L., and M. Joecylyn, "YANG Data Model
draft-shah-bess-l2vpn-yang-01 (work in progress), March for MPLS-based L2VPN", draft-shah-bess-l2vpn-yang-01 (work
2016. in progress), March 2016.
[I-D.zhang-ccamp-transport-ctrlnorth-yang] [I-D.zhang-ccamp-transport-ctrlnorth-yang]
Zhang, X., Jing, R., Jian, W., Ryoo, J., Xu, Y., and D. Zhang, X., Jing, R., Jian, W., Ryoo, J., Xu, Y., and D.
King, "YANG Models for the Northbound Interface of a King, "YANG Models for the Northbound Interface of a
Transport Network Controller: Requirements, Functions, and Transport Network Controller: Requirements, Functions, and
a List of YANG Models", draft-zhang-ccamp-transport- a List of YANG Models", draft-zhang-ccamp-transport-
ctrlnorth-yang-00 (work in progress), March 2016. ctrlnorth-yang-00 (work in progress), March 2016.
[I-D.zheng-mpls-lsp-ping-yang-cfg] [I-D.zheng-mpls-lsp-ping-yang-cfg]
Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R.
skipping to change at page 43, line 26 skipping to change at page 46, line 5
"Framework for Policy Usage Feedback for Common Open "Framework for Policy Usage Feedback for Common Open
Policy Service with Policy Provisioning (COPS-PR)", Policy Service with Policy Provisioning (COPS-PR)",
RFC 3483, DOI 10.17487/RFC3483, March 2003, RFC 3483, DOI 10.17487/RFC3483, March 2003,
<http://www.rfc-editor.org/info/rfc3483>. <http://www.rfc-editor.org/info/rfc3483>.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, Protocol version 6 (IPv6)", RFC 3484,
DOI 10.17487/RFC3484, February 2003, DOI 10.17487/RFC3484, February 2003,
<http://www.rfc-editor.org/info/rfc3484>. <http://www.rfc-editor.org/info/rfc3484>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, DOI 10.17487/RFC4080, June 2005, RFC 4080, DOI 10.17487/RFC4080, June 2005,
<http://www.rfc-editor.org/info/rfc4080>. <http://www.rfc-editor.org/info/rfc4080>.
[RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy
Service (COPS) Over Transport Layer Security (TLS)", Service (COPS) Over Transport Layer Security (TLS)",
RFC 4261, DOI 10.17487/RFC4261, December 2005, RFC 4261, DOI 10.17487/RFC4261, December 2005,
<http://www.rfc-editor.org/info/rfc4261>. <http://www.rfc-editor.org/info/rfc4261>.
 End of changes. 35 change blocks. 
64 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/