--- 1/draft-ietf-i2nsf-gap-analysis-01.txt 2016-07-20 22:16:00.533175959 -0700 +++ 2/draft-ietf-i2nsf-gap-analysis-02.txt 2016-07-20 22:16:00.621178152 -0700 @@ -1,19 +1,19 @@ I2NSF WG S. Hares Internet-Draft R. Moskowitz Intended status: Informational Huawei -Expires: October 6, 2016 D. Zhang - April 4, 2016 +Expires: January 21, 2017 D. Zhang + July 20, 2016 Analysis of Existing work for I2NSF - draft-ietf-i2nsf-gap-analysis-01.txt + draft-ietf-i2nsf-gap-analysis-02.txt Abstract This document analyzes the current state of the art for security management devices and security devices technologies in industries and the existing IETF work/protocols that are relevant to the Interface to Network Security Function (I2NSF). The I2NSF focus is to define data models and interfaces in order to control and monitor the physical and virtual aspects of network security functions. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,21 +54,21 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. What is I2NSF . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Structure of this Document . . . . . . . . . . . . . . . 4 1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5 1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5 1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9 - 2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 9 + 2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 10 3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13 3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 15 4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15 4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17 5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17 5.1. Overview of API for Security Group . . . . . . . . . . . 18 5.2. Overview of Firewall as a Service . . . . . . . . . . . . 18 5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19 @@ -79,34 +79,38 @@ 6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22 6.1.4. Web Security (Web) . . . . . . . . . . . . . . . . . 23 6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24 6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25 6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26 6.1.8. Security Information and Event Management(SIEM) . . . 27 6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28 6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29 6.1.11. Network Security Devices . . . . . . . . . . . . . . 30 6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31 - 7. In-depth Review of IETF protocols . . . . . . . . . . . . . . 31 - 7.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 31 - 7.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 32 - 7.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 33 - 7.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 7.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 7.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 35 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 11.2. Informative References . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 + 7. IEEE security . . . . . . . . . . . . . . . . . . . . . . . . 31 + 7.1. Port-based Network Access Control [802.1X] . . . . . . . 31 + 7.2. MAC security (802.1AE) . . . . . . . . . . . . . . . . . 32 + 7.3. Secure Device Identity [802.1AR] . . . . . . . . . . . . 33 + 8. In-depth Review of IETF protocols . . . . . . . . . . . . . . 34 + 8.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 34 + 8.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 35 + 8.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 35 + 8.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 8.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 8.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 38 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 12.2. Informative References . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction This documents provides a gap analysis for I2NSF. 1.1. What is I2NSF A Network Security Function (NSF) ensures integrity, confidentiality and availability of network communications, detects unwanted activity, and/or blocks out or at least mitigates the effects of @@ -1442,23 +1447,138 @@ 6.2. I2NSF Gap Analysis 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 neutral, inoperable protocol that allow the multiple of network security devices to communicate passing provisioning and informational data. Each of the 10 implementation agreements points to this as a shortcoming. Standard I2NSF YANG models and an I2NSF 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 NETCONF protocol focusing on secure configuration and querying operational state. The NETCONF protocol [RFC6241] may be run over TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults [RFC6243], handling events ([RFC5277] and basic notification [RFC6470], and filtering writes/reads based on network access control models (NACM, [RFC6536]). The NETCONF configuration must be committed to a configuration data store (denoted as config=TRUE). YANG models identify nodes within a configuration data store or an @@ -1493,21 +1612,21 @@ o RESTCONF [I-D.ietf-netconf-restconf] o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home] o RESTCONF collection protocol [I-D.ietf-netconf-restconf-collection] 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 decided to re-use the NETCONF or RESTCONF protocols and specify additions to these protocols rather than create yet another protocol (YAP). The required extensions for the I2RS protocol are in the following drafts: o [I-D.ietf-i2rs-ephemeral-state], @@ -1517,21 +1636,21 @@ o [I-D.ietf-i2rs-traceability] o [I-D.ietf-i2rs-protocol-security-requirements] At this time, NETCONF and RESTCONF cannot handle the ephemeral data store proposed by I2RS, the publication and subscription requirements, the traceability, or the security requirements for the transport protocol and message integrity. -7.3. NETMOD YANG modules +8.3. NETMOD YANG modules NETMOD developed initial YANG models for interfaces [RFC7223]), IP address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP Systems ([RFC7317]) with system ID, system time management, DNS resolver, Radius client, SSH, syslog ([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 working group (rtgwg) has begun to examine policy for routing and tunnels. @@ -1547,29 +1666,30 @@ o L3VPN [I-D.li-bess-l3vpn-yang] and [I-D.hu-bess-l2vpn-service-yang], TEAS working group has proposed [I-D.ietf-teas-yang-te-topo], and [I-D.ietf-teas-yang-rsvp]. MPLS/PCE/CCAMP groups have proposed the following Yang modules: o [I-D.raza-mpls-ldp-mldp-yang] + o [I-D.saad-mpls-static-yang], o [I-D.zheng-mpls-lsp-ping-yang-cfg], o [I-D.pkd-pce-pcep-yang], and 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 traffic entering a network is the 1990s COPS [RFC2748] design (PEP and PDP) as shown in Figure 11. The COPS policy decision points (PDP) managed network-wide policy (e.g. ACLs) by installing this policy in policy enforcement points (PEPs) on the edge of the 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 network at a PEP. [RFC3084] describes COPS usages for policy provisioning. @@ -1596,21 +1716,21 @@ Why I2NSF is Different from COPS COPS was a protocol for policy related to Quality of Service (QoS) and signaling protocols (e.g. RSVP) (security, flow, and others). I2NSF creates a common protocol between security policy decision points (SPDP) and security enforcement points (SEP). Today's security devices currently only use proprietary protocols. Manufacturers would like a security specific policy enforcement 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 IPv4 or IPv6 host to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts. PCP RFCs: [RFC6887] @@ -1622,21 +1742,21 @@ [I-D.ietf-pcp-proxy] Why is I2NSF Different from PCP: Here are some aspects that I2NSF is different from PCP: o PCP only supports management of port and address information 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 data path for end points to request their unique QoS characteristics, unique FW policies or NAT needs (RFC5973) that are different from the FW/NAT original settings. The requests are communicated directly to the FW/NAT devices. NSIS is like east-west protocols that require all involved devices to fully comply to make it work. NSIS is path-coupled; it is possible to message every participating device along a path without having to know its location, or its @@ -1687,49 +1807,49 @@ interoperable protocols that span controllers/routers, middle- boxes, and security end-systems. o IETF has a history of working on interoperable protocols or virtualized network functions (L2VPN, L3VPN) that are deployed by operators in large scale devices. IETF has a strong momentum to create virtualized network functions (see SFC WG in routing) to be deployed in network boxes. [Note: We need to add SACM and others here]. -8. IANA Considerations +9. IANA Considerations No IANA considerations exist for this document. -9. Security Considerations +10. Security Considerations No security considerations are involved with a gap analysis. -10. Contributors +11. Contributors The following people have contributed to this document: Hosnieh Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive comments, great suggestions, and valuable insights on alternative views. -11. References +12. References -11.1. Normative References +12.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . -11.2. Informative References +12.2. Informative References [I-D.brissette-bess-evpn-yang] Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh, T., and I. Hussain, "Yang Data Model for EVPN", draft- brissette-bess-evpn-yang-01 (work in progress), December 2015. [I-D.hares-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., and L. Xia, "I2NSF Terminology", draft-hares-i2nsf-terminology-00 (work in @@ -1751,76 +1871,76 @@ March 2016. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-11 (work in progress), December 2015. [I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State - Requirements", draft-ietf-i2rs-ephemeral-state-05 (work in - progress), March 2016. + Requirements", draft-ietf-i2rs-ephemeral-state-14 (work in + progress), July 2016. [I-D.ietf-i2rs-problem-statement] Atlas, A., Nadeau, T., and D. Ward, "Interface to the 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] Hares, S., Migault, D., and J. Halpern, "I2RS 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] Voit, E., Clemm, A., and A. Prieto, "Requirements for 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] Wang, L., Ananthakrishnan, H., Chen, M., amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A YANG Data Model for Routing Information Base (RIB)", - draft-ietf-i2rs-rib-data-model-05 (work in progress), - March 2016. + draft-ietf-i2rs-rib-data-model-06 (work in progress), July + 2016. [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Kini, S., and J. Medved, "Routing Information - Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work - in progress), October 2015. + Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work + in progress), July 2016. [I-D.ietf-i2rs-traceability] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and - Information Model", draft-ietf-i2rs-traceability-07 (work - in progress), February 2016. + Information Model", draft-ietf-i2rs-traceability-11 (work + in progress), May 2016. [I-D.ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 (work in progress), May 2015. [I-D.ietf-i2rs-yang-l2-network-topology] Dong, J. and X. Wei, "A YANG Data Model for Layer-2 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] Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., - and H. Ananthakrishnan, "A Data Model for Network - Topologies", draft-ietf-i2rs-yang-network-topo-02 (work in - progress), December 2015. + Ananthakrishnan, H., and X. Liu, "A Data Model for Network + Topologies", draft-ietf-i2rs-yang-network-topo-04 (work in + progress), July 2016. [I-D.ietf-idr-bgp-model] Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., - Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. - Liu, "BGP Model for Service Provider Networks", draft- + Bansal, D., Clemm, A., Zhdankin, A., Jethanandani, M., and + X. Liu, "BGP Model for Service Provider Networks", draft- ietf-idr-bgp-model-01 (work in progress), January 2016. [I-D.ietf-isis-yang-isis-cfg] Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- isis-yang-isis-cfg-02 (work in progress), March 2015. [I-D.ietf-l3sm-l3vpn-service-model] Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K. D'Souza, "YANG Data Model for L3VPN service delivery", @@ -1904,58 +2024,58 @@ [I-D.ietf-teas-yang-rsvp] Beeram, V., Saad, T., Gandhi, R., Liu, X., Shah, H., Chen, X., Jones, R., and B. Wen, "A YANG Data Model for Resource Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp-03 (work in progress), March 2016. [I-D.ietf-teas-yang-te-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 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] Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, R., Bogdanovic, D., and R. White, "Filter-Based RIB Information Model", draft-kini-i2rs-fb-rib-info-model-03 (work in progress), February 2016. [I-D.li-bess-l3vpn-yang] Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess- l3vpn-yang-00 (work in progress), October 2015. [I-D.pkd-pce-pcep-yang] - Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A - YANG Data Model for Path Computation Element - Communications Protocol (PCEP)", draft-pkd-pce-pcep- - yang-05 (work in progress), January 2016. + Dhody, D., Hardwick, J., Beeram, V., and j. + jefftant@gmail.com, "A YANG Data Model for Path + Computation Element Communications Protocol (PCEP)", + draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. [I-D.raza-mpls-ldp-mldp-yang] Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H. 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] - Raza, K., Gandhi, R., Liu, X., Beeram, V., Saad, T., Chen, - X., Jones, R., and B. Wen, "A YANG Data Model for MPLS - Base and Static LSPs", draft-saad-mpls-static-yang-02 - (work in progress), March 2016. + Saad, T., Raza, K., Gandhi, R., Liu, X., Beeram, V., Shah, + H., Bryskin, I., Chen, X., Jones, R., and B. Wen, "A YANG + Data Model for MPLS Static LSPs", draft-saad-mpls-static- + yang-03 (work in progress), May 2016. [I-D.shah-bess-l2vpn-yang] Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z., Zhuang, S., Wang, H., Chen, I., Ahmed, S., Bocci, M., - Hardwick, J., Esale, S., Tiruveedhula, K., Singh, T., - Hussain, I., Wen, B., Walker, J., Delregno, N., Jalil, L., - and M. Joecylyn, "YANG Data Model for MPLS-based L2VPN", - draft-shah-bess-l2vpn-yang-01 (work in progress), March - 2016. + Hardwick, J., Esale, S., Tiruveedhula, K., + tsingh@juniper.net, t., Hussain, I., Wen, B., Walker, J., + Delregno, N., Jalil, L., and M. Joecylyn, "YANG Data Model + for MPLS-based L2VPN", draft-shah-bess-l2vpn-yang-01 (work + in progress), March 2016. [I-D.zhang-ccamp-transport-ctrlnorth-yang] Zhang, X., Jing, R., Jian, W., Ryoo, J., Xu, Y., and D. King, "YANG Models for the Northbound Interface of a Transport Network Controller: Requirements, Functions, and a List of YANG Models", draft-zhang-ccamp-transport- ctrlnorth-yang-00 (work in progress), March 2016. [I-D.zheng-mpls-lsp-ping-yang-cfg] Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. @@ -1992,20 +2112,25 @@ "Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)", RFC 3483, DOI 10.17487/RFC3483, March 2003, . [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/RFC3484, February 2003, . + [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, + . + [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, DOI 10.17487/RFC4080, June 2005, . [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy Service (COPS) Over Transport Layer Security (TLS)", RFC 4261, DOI 10.17487/RFC4261, December 2005, .