< draft-ietf-rtgwg-yang-key-chain-06.txt		draft-ietf-rtgwg-yang-key-chain-07.txt >
	Network Working Group A. Lindem, Ed.		Network Working Group A. Lindem, Ed.
	Internet-Draft Y. Qu		Internet-Draft Y. Qu
	Intended status: Standards Track D. Yeung		Intended status: Standards Track D. Yeung
	Expires: December 30, 2016 Cisco Systems		Expires: February 18, 2017 Cisco Systems
	I. Chen		I. Chen
	Ericsson		Ericsson
	J. Zhang		J. Zhang
	Juniper Networks		Juniper Networks
	Y. Yang		Y. Yang
	Cisco Systems		Cisco Systems
	June 28, 2016		August 17, 2016
	Routing Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-06.txt		draft-ietf-rtgwg-yang-key-chain-07.txt
	Abstract		Abstract
	This document describes the key chain YANG data model. A key chain		This document describes the key chain YANG data model. A key chain
	is a list of elements each containing a key, send lifetime, accept		is a list of elements each containing a key, send lifetime, accept
	lifetime, and algorithm. By properly overlapping the send and accept		lifetime, and algorithm. By properly overlapping the send and accept
	lifetimes of multiple key chain elements, keys and algorithms may be		lifetimes of multiple key chain elements, keys and algorithms may be
	gracefully updated. By representing them in a YANG data model, key		gracefully updated. By representing them in a YANG data model, key
	distribution can be automated. Key chains are commonly used for		distribution can be automated. Key chains are commonly used for
	routing protocol authentication and other applications. In some		routing protocol authentication and other applications. In some
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 December 30, 2016.		This Internet-Draft will expire on February 18, 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 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3		2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3
	3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4		3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4
	3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5		3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5
	3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5		3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5
	3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5		3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5
	4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8		4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8
	5. Relationship to other Work . . . . . . . . . . . . . . . . . 17		5. Relationship to other Work . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	This document describes the key chain YANG data model. A key chain		This document describes the key chain YANG data model. A key chain
	is a list of elements each containing a key, send lifetime, accept		is a list of elements each containing a key, send lifetime, accept
	lifetime, and algorithm. By properly overlapping the send and accept		lifetime, and algorithm. By properly overlapping the send and accept
	lifetimes of multiple key chain elements, keys and algorithms may be		lifetimes of multiple key chain elements, keys and algorithms may be
	gracefully updated. By representing them in a YANG data model, key		gracefully updated. By representing them in a YANG data model, key
	distribution can be automated. Key chains are commonly used for		distribution can be automated. Key chains are commonly used for
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	A key-chain is identified by a unique name within the scope of the		A key-chain is identified by a unique name within the scope of the
	network device. The "key-chain-ref" typedef SHOULD be used by other		network device. The "key-chain-ref" typedef SHOULD be used by other
	YANG modules when they need to reference a configured key-chain.		YANG modules when they need to reference a configured key-chain.
	3.1. Key Chain Operational State		3.1. Key Chain Operational State
	The key chain operational state is maintained in the key-chain		The key chain operational state is maintained in the key-chain
	entries along with the configuration state. The key string itself is		entries along with the configuration state. The key string itself is
	omitted from the operational state to minimize visibility similar to		omitted from the operational state to minimize visibility similar to
	what was done with keys in SNMP MIBs. This is an area for further		what was done with keys in SNMP MIBs. The timestamp of the last key-
	discussion. Additionally, the operational state includes an		chain modification is also maintained in the operational state.
	indication of whether or not a key chain entry is valid for sending		Additionally, the operational state includes an indication of whether
	or acceptance.		or not a key chain entry is valid for sending or acceptance.
	3.2. Key Chain Model Features		3.2. Key Chain Model Features
	Features are used to handle differences between vendor		Features are used to handle differences between vendor
	implementations. For example, not all vendors support configuration		implementations. For example, not all vendors support configuration
	an acceptance tolerance or configuration of key strings in		an acceptance tolerance or configuration of key strings in
	hexadecimal. They are also used to support of security requirements		hexadecimal. They are also used to support of security requirements
	(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by		(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by
	vendors or only a single vendor.		vendors or only a single vendor.
	3.3. Key Chain Model Tree		3.3. Key Chain Model Tree
	module: ietf-key-chain		module: ietf-key-chain
	+-rw key-chains		+--rw key-chains
	+--rw key-chain-list* [name]		+--rw key-chain-list* [name]
	| +--rw name string		| +--rw name string
	| +--ro name-state? string		| +--ro name-state? string
			| +--rw description? string
	| +--rw accept-tolerance {accept-tolerance}?		| +--rw accept-tolerance {accept-tolerance}?
	| | +--rw duration? uint32		| | +--rw duration? uint32
	| +--ro accept-tolerance-state		| +--ro accept-tolerance-state
	| | +--ro duration? uint32		| | +--ro duration? uint32
			| +--ro last-modified-timestamp? yang:date-and-time
	| +--rw key-chain-entry* [key-id]		| +--rw key-chain-entry* [key-id]
	| +--rw key-id uint64		| +--rw key-id uint64
	| +--ro key-id-state? uint64		| +--ro key-id-state? uint64
	| +--rw key-string		| +--rw key-string
	| | +--rw (key-string-style)?		| | +--rw (key-string-style)?
	| | +--:(keystring)		| | +--:(keystring)
	| | | +--rw keystring? string		| | | +--rw keystring? string
	| | +--:(hexadecimal) {hex-key-string}?		| | +--:(hexadecimal) {hex-key-string}?
	| | +--rw hexadecimal-string? yang:hex-string		| | +--rw hexadecimal-string? yang:hex-string
	| +--rw lifetime		| +--rw lifetime
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 17 ¶
	| | | | +--rw always? empty		| | | | +--rw always? empty
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--rw start-date-time? yang:date-and-time		| | | +--rw start-date-time? yang:date-and-time
	| | | +--rw (end-time)?		| | | +--rw (end-time)?
	| | | +--:(infinite)		| | | +--:(infinite)
	| | | | +--rw no-end-time? empty		| | | | +--rw no-end-time? empty
	| | | +--:(duration)		| | | +--:(duration)
	| | | | +--rw duration? uint32		| | | | +--rw duration? uint32
	| | | +--:(end-date-time)		| | | +--:(end-date-time)
	| | | +--rw end-date-time?		| | | +--rw end-date-time?
	| | | yang:date-and-time		| | | yang:date-and-time
	| | +--:(independent-send-accept-lifetime)		| | +--:(independent-send-accept-lifetime)
	| | | {independent-send-accept-lifetime}?		| | {independent-send-accept-lifetime}?
	| | +--rw send-lifetime		| | +--rw send-lifetime
	| | | +--rw (lifetime)?		| | | +--rw (lifetime)?
	| | | +--:(always)		| | | +--:(always)
	| | | | +--rw always? empty		| | | | +--rw always? empty
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--rw start-date-time? yang:date-and-time		| | | +--rw start-date-time? yang:date-and-time
	| | | +--rw (end-time)?		| | | +--rw (end-time)?
	| | | +--:(infinite)		| | | +--:(infinite)
	| | | | +--rw no-end-time? empty		| | | | +--rw no-end-time? empty
	| | | +--:(duration)		| | | +--:(duration)
	| | | | +--rw duration? uint32		| | | | +--rw duration? uint32
	| | | +--:(end-date-time)		| | | +--:(end-date-time)
	| | | +--rw end-date-time?		| | | +--rw end-date-time?
	| | | yang:date-and-time		| | | yang:date-and-time
	| | +--rw accept-lifetime		| | +--rw accept-lifetime
	| | +--rw (lifetime)?		| | +--rw (lifetime)?
	| | +--:(always)		| | +--:(always)
	| | | +--rw always? empty		| | | +--rw always? empty
	| | +--:(start-end-time)		| | +--:(start-end-time)
	| | +--rw start-date-time? yang:date-and-time		| | +--rw start-date-time? yang:date-and-time
	| | +--rw (end-time)?		| | +--rw (end-time)?
	| | +--:(infinite)		| | +--:(infinite)
	| | | +--rw no-end-time? empty		| | | +--rw no-end-time? empty
	| | +--:(duration)		| | +--:(duration)
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 32 ¶
	| | +--ro clear-text? empty		| | +--ro clear-text? empty
	| +--:(replay-protection-only) {replay-protection-only}?		| +--:(replay-protection-only) {replay-protection-only}?
	| +--ro replay-protection-only? empty		| +--ro replay-protection-only? empty
	+--rw aes-key-wrap {aes-key-wrap}?		+--rw aes-key-wrap {aes-key-wrap}?
	| +--rw enable? boolean		| +--rw enable? boolean
	+--ro aes-key-wrap-state {aes-key-wrap}?		+--ro aes-key-wrap-state {aes-key-wrap}?
	+--ro enable? boolean		+--ro enable? boolean
	4. Key Chain YANG Model		4. Key Chain YANG Model
	<CODE BEGINS> file "ietf-key-chain@2016-06-28.yang"		<CODE BEGINS> file "ietf-key-chain@2016-08-17.yang"
	module ietf-key-chain {		module ietf-key-chain {
	namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";		namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";
	// replace with IANA namespace when assigned		// replace with IANA namespace when assigned
	prefix "key-chain";		prefix "key-chain";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
	organization		organization
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 17 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2016-06-28 {		revision 2016-08-17 {
			description
			"Add description and last-modified timestamp leaves.";
			reference
			"RFC XXXX: A YANG Data Model for key-chain";
			}
			revision 2016-07-01 {
	description		description
	"Rename module back to ietf-key-chain.		"Rename module back to ietf-key-chain.
	Added replay-protection-only feature and algorithm.";		Added replay-protection-only feature and algorithm.";
	reference		reference
	"RFC XXXX: A YANG Data Model for key-chain";		"RFC XXXX: A YANG Data Model for key-chain";
	}		}
	revision 2016-03-15 {		revision 2016-03-15 {
	description		description
	"Rename module from ietf-key-chain to		"Rename module from ietf-key-chain to
	ietf-routing-key-chain.";		ietf-routing-key-chain.";
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 51 ¶
	reference		reference
	"RFC XXXX: A YANG Data Model for key-chain";		"RFC XXXX: A YANG Data Model for key-chain";
	}		}
	revision 2015-10-15 {		revision 2015-10-15 {
	description		description
	"Updated version, organization, and copyright.		"Updated version, organization, and copyright.
	Added aes-cmac-prf-128 and aes-key-wrap features.";		Added aes-cmac-prf-128 and aes-key-wrap features.";
	reference		reference
	"RFC XXXX: A YANG Data Model for key-chain";		"RFC XXXX: A YANG Data Model for key-chain";
	}		}
	revision 2015-06-28 {		revision 2015-06-29 {
	description		description
	"Updated version. Added Operation State following		"Updated version. Added Operation State following
	draft-openconfig-netmod-opstate-00.";		draft-openconfig-netmod-opstate-00.";
	reference		reference
	"RFC XXXX: A YANG Data Model for key-chain";		"RFC XXXX: A YANG Data Model for key-chain";
	}		}
	revision 2015-02-24 {		revision 2015-02-24 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	skipping to change at page 13, line 45 ¶		skipping to change at page 14, line 4 ¶
	if-feature replay-protection-only;		if-feature replay-protection-only;
	leaf replay-protection-only {		leaf replay-protection-only {
	type empty;		type empty;
	description		description
	"Provide replay-protection without any authentication		"Provide replay-protection without any authentication
	as required by protocols such as Bidirectional		as required by protocols such as Bidirectional
	Forwarding Detection (BFD).";		Forwarding Detection (BFD).";
	}		}
	}		}
	}		}
	}		}
	grouping key-chain {		grouping key-chain {
	description		description
	"key-chain specification grouping.";		"key-chain specification grouping.";
	leaf name {		leaf name {
	type string;		type string;
	description "Name of the key-chain.";		description "Name of the key-chain.";
	}		}
	leaf name-state {		leaf name-state {
	type string;		type string;
	config false;		config false;
	description "Configured name of the key-chain.";		description "Configured name of the key-chain.";
	}		}
			leaf description {
			type string;
			description "A description of the key-chain";
			}
	container accept-tolerance {		container accept-tolerance {
	if-feature accept-tolerance;		if-feature accept-tolerance;
	description		description
	"Tolerance for key lifetime acceptance (seconds).";		"Tolerance for key lifetime acceptance (seconds).";
	leaf duration {		leaf duration {
	type uint32;		type uint32;
	units seconds;		units seconds;
	default "0";		default "0";
	description		description
	"Tolerance range, in seconds.";		"Tolerance range, in seconds.";
	skipping to change at page 14, line 38 ¶		skipping to change at page 14, line 51 ¶
	description		description
	"Configured tolerance for key lifetime		"Configured tolerance for key lifetime
	acceptance (seconds).";		acceptance (seconds).";
	leaf duration {		leaf duration {
	type uint32;		type uint32;
	description		description
	"Configured tolerance range, in seconds.";		"Configured tolerance range, in seconds.";
	}		}
	}		}
			leaf last-modified-timestamp {
			type yang:date-and-time;
			config false;
			description "Timestamp of the most recent update
			to the key-chain";
			}
	list key-chain-entry {		list key-chain-entry {
	key "key-id";		key "key-id";
	description "One key.";		description "One key.";
	leaf key-id {		leaf key-id {
	type uint64;		type uint64;
	description "Key ID.";		description "Key ID.";
	}		}
	leaf key-id-state {		leaf key-id-state {
	type uint64;		type uint64;
	config false;		config false;
End of changes. 20 change blocks.
	22 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/