Diff: draft-smith-kandula-sxp-06.txt - draft-smith-kandula-sxp-07.txt

	< draft-smith-kandula-sxp-06.txt	draft-smith-kandula-sxp-07.txt >

	Network Working Group M. Smith	Network Working Group M. Smith
	Internet-Draft R. Kandula	Internet-Draft R. Kandula

	Intended status: Informational Cisco Systems	Intended status: Informational Appala
	Expires: December 3, 2017 June 1, 2017	Expires: October 5, 2019 Cisco Systems
		April 3, 2019

	Scalable-Group Tag eXchange Protocol (SXP)	Scalable-Group Tag eXchange Protocol (SXP)

	draft-smith-kandula-sxp-06	draft-smith-kandula-sxp-07

	Abstract	Abstract

	This document discusses scalable-group tag exchange protocol (SXP), a	This document discusses scalable-group tag exchange protocol (SXP), a
	control protocol to propagate IP address to Scalable Group Tag (SGT)	control protocol to propagate IP address to Scalable Group Tag (SGT)
	binding information across network devices.	binding information across network devices.

	Requirements Language	Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

	skipping to change at page 1, line 31 ¶	skipping to change at page 1, line 32 ¶
	document are to be interpreted as described in [RFC2119].	document are to be interpreted as described in [RFC2119].

	Status of This Memo	Status of This Memo

	This Internet-Draft is submitted in full conformance with the	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.	provisions of BCP 78 and BCP 79.

	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 https://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 3, 2017.	This Internet-Draft will expire on October 5, 2019.

	Copyright Notice	Copyright Notice


	Copyright (c) 2017 IETF Trust and the persons identified as the	Copyright (c) 2019 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	(https://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
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	This document may not be modified, and derivative works of it may not	This document may not be modified, and derivative works of it may not
	be created, except to format it for publication as an RFC or to	be created, except to format it for publication as an RFC or to
	translate it into languages other than English.	translate it into languages other than English.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. SXP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4	2. SXP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. SXP Operation . . . . . . . . . . . . . . . . . . . . . . . . 5	3. SXP Operation . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. SXP Connection Management . . . . . . . . . . . . . . . . 5	3.1. SXP Connection Management . . . . . . . . . . . . . . . . 5
	3.1.1. SXP Connection . . . . . . . . . . . . . . . . . . . 5	3.1.1. SXP Connection . . . . . . . . . . . . . . . . . . . 5
	3.1.2. SXP Message integrity/authenticity . . . . . . . . . 6	3.1.2. SXP Message integrity/authenticity . . . . . . . . . 6

	3.1.3. SXP Connectivity Discovery and Connection Recovery . 6	3.1.3. SXP Connectivity Discovery and Connection Recovery . 7
	3.1.4. SXP Connection Setup Sequence . . . . . . . . . . . . 7	3.1.4. SXP Connection Setup Sequence . . . . . . . . . . . . 7

	3.1.5. SXP Connection States . . . . . . . . . . . . . . . . 7	3.1.5. SXP Connection States . . . . . . . . . . . . . . . . 8
	3.2. Binding Database . . . . . . . . . . . . . . . . . . . . 8	3.2. Binding Database . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. SXP Learned IP-SGT Binding recovery . . . . . . . . . 9	3.2.1. SXP Learned IP-SGT Binding recovery . . . . . . . . . 9
	4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9	4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Bit and Octet Numbering Convention . . . . . . . . . . . 9	4.1. Bit and Octet Numbering Convention . . . . . . . . . . . 9

	4.2. SXP Message Header . . . . . . . . . . . . . . . . . . . 9	4.2. SXP Message Header . . . . . . . . . . . . . . . . . . . 10
	4.3. Attribute Formats . . . . . . . . . . . . . . . . . . . . 10	4.3. Attribute Formats . . . . . . . . . . . . . . . . . . . . 10
	4.4. SXP OPEN and OPEN_RESP Message . . . . . . . . . . . . . 13	4.4. SXP OPEN and OPEN_RESP Message . . . . . . . . . . . . . 13
	4.4.1. Node-ID . . . . . . . . . . . . . . . . . . . . . . . 14	4.4.1. Node-ID . . . . . . . . . . . . . . . . . . . . . . . 14
	4.4.2. Capabilities Advertisement . . . . . . . . . . . . . 14	4.4.2. Capabilities Advertisement . . . . . . . . . . . . . 14
	4.4.3. Keep-alive and Hold Time Negotiation . . . . . . . . 17	4.4.3. Keep-alive and Hold Time Negotiation . . . . . . . . 17
	4.5. SXP UPDATE Message . . . . . . . . . . . . . . . . . . . 22	4.5. SXP UPDATE Message . . . . . . . . . . . . . . . . . . . 22
	4.5.1. UPDATE Attributes . . . . . . . . . . . . . . . . . . 23	4.5.1. UPDATE Attributes . . . . . . . . . . . . . . . . . . 23
	4.5.2. UPDATE Message Samples . . . . . . . . . . . . . . . 32	4.5.2. UPDATE Message Samples . . . . . . . . . . . . . . . 32
	4.6. SXP ERROR Message . . . . . . . . . . . . . . . . . . . . 35	4.6. SXP ERROR Message . . . . . . . . . . . . . . . . . . . . 35
	4.6.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 36	4.6.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 36

	skipping to change at page 6, line 14 ¶	skipping to change at page 6, line 14 ¶

	* The SXP speaker is responsible for sending the IP-SGT bindings.	* The SXP speaker is responsible for sending the IP-SGT bindings.

	* The SXP listener is responsible for collecting the IP-SGT	* The SXP listener is responsible for collecting the IP-SGT
	bindings received from the speaker peer and also merge the	bindings received from the speaker peer and also merge the
	bindings received from multiple connections.	bindings received from multiple connections.

	o SXP connection password	o SXP connection password

	* If SXP data integrity and authentication are required, then	* If SXP data integrity and authentication are required, then

	both the peer devices must have same SXP password.	both the peer devices must have same authentication mechanism
		(MD5 or TCP-AO). The passwords should match on both the peers
		in case of MD5 and similarly the key-chains in case of TCP-AO.

	3.1.2. SXP Message integrity/authenticity	3.1.2. SXP Message integrity/authenticity


		3.1.2.1. SXP Connection Using MD5

	The connection peers on the 2 network devices supply the same SXP	The connection peers on the 2 network devices supply the same SXP
	password to the TCP layer which will authenticate all further	password to the TCP layer which will authenticate all further
	messages using the MD5 algorithm (RFC 2385). The SXP payload is not	messages using the MD5 algorithm (RFC 2385). The SXP payload is not
	encrypted because the main requirement is for the receiving device to	encrypted because the main requirement is for the receiving device to
	determine that the message originated from a valid source and not to	determine that the message originated from a valid source and not to
	prevent snooping of message (discussed in security considerations	prevent snooping of message (discussed in security considerations
	section) payload. SXP uses the underlying TCP MD5 option for message	section) payload. SXP uses the underlying TCP MD5 option for message
	integrity/authenticity. The TCP MD5 is exchanged (negotiated) during	integrity/authenticity. The TCP MD5 is exchanged (negotiated) during
	the initial TCP 3 way handshake. Both sides (peers) are pre-	the initial TCP 3 way handshake. Both sides (peers) are pre-
	configured with the keys (password) which will be used for forming	configured with the keys (password) which will be used for forming
	the MD5 digest. Each packet (segment) needs to be "signed" with the	the MD5 digest. Each packet (segment) needs to be "signed" with the
	MD5 digest (16 bytes) formed using the password as the key.	MD5 digest (16 bytes) formed using the password as the key.

	Whenever the password needs to be changed for an existing TCP	Whenever the password needs to be changed for an existing TCP
	connection, the peer resets the existing TCP connection and sets up a	connection, the peer resets the existing TCP connection and sets up a
	new TCP connection with the new password. Changing the default	new TCP connection with the new password. Changing the default
	password will cause all SXP connections using the default password to	password will cause all SXP connections using the default password to
	be re-established.	be re-established.


		3.1.2.2. SXP Connection Using TCP-AO

		The connection peers on the 2 network devices can authenticate each
		other using TCP-AO (RFC 5925). SXP uses the underlying TCP-AO option
		for message integrity/authenticity. The TCP-AO option is exchanged
		(negotiated) during the initial TCP 3 way handshake. Both sides
		(peers) are pre-configured with the keys which will be used for
		forming the HMAC. The TCP module will populate the TCP-AO option in
		each outgoing segment by generating the HMAC using the traffic keys.
		On the receiver, TCP will generate the HMAC using the traffic keys
		and incoming segment header to validate the HMAC in the incoming TCP-
		AO option.

		Whenever the TCP-AO key-chain needs to be changed for an existing TCP
		connection, the peer resets the existing TCP connection and sets up a
		new TCP connection with the new key-chain. Changing the default key-
		chain will cause all SXP connections using the default key-chain to
		be re-established.

	3.1.3. SXP Connectivity Discovery and Connection Recovery	3.1.3. SXP Connectivity Discovery and Connection Recovery

	SXP uses the TCP keep alive mechanism with the default behavior to	SXP uses the TCP keep alive mechanism with the default behavior to
	maintain SXP connectivity. A SXP device attempts to maintain	maintain SXP connectivity. A SXP device attempts to maintain
	connectivity with each peer. In case of failures, the SXP device	connectivity with each peer. In case of failures, the SXP device
	continues to retry connection setup with all the peers with which the	continues to retry connection setup with all the peers with which the
	SXP connections have not been established. This continues until	SXP connections have not been established. This continues until
	either a connection is established or the peer is removed from the	either a connection is established or the peer is removed from the
	peer set by a change in configuration. This mechanism ensures	peer set by a change in configuration. This mechanism ensures
	automatic recovery of the SXP connection once the connectivity issue	automatic recovery of the SXP connection once the connectivity issue

	skipping to change at page 50, line 45 ¶	skipping to change at page 50, line 45 ¶
	VxLan and also the section on tagging exemption for L2 control	VxLan and also the section on tagging exemption for L2 control
	traffic. Thanks to Joe Salowey and Susan Thomson for edits and	traffic. Thanks to Joe Salowey and Susan Thomson for edits and
	review.	review.

	15. References	15. References

	15.1. Normative References	15.1. Normative References

	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	DOI 10.17487/RFC1321, April 1992,	DOI 10.17487/RFC1321, April 1992,

	<http://www.rfc-editor.org/info/rfc1321>.	<https://www.rfc-editor.org/info/rfc1321>.

	[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>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,

	June 2010, <http://www.rfc-editor.org/info/rfc5925>.	June 2010, <https://www.rfc-editor.org/info/rfc5925>.

		[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
		for the TCP Authentication Option (TCP-AO)", June 2010,
		<https://www.rfc-editor.org/info/rfc5926>.

	15.2. Informative References	15.2. Informative References

	[I-D.draft-guichard-sfc-nsh-dc-allocation]	[I-D.draft-guichard-sfc-nsh-dc-allocation]
	Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,	Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
	P., Glavin, K., and Y. Laribi, "Network Service Header	P., Glavin, K., and Y. Laribi, "Network Service Header
	(NSH) Context Header Allocation (Data Center)", December	(NSH) Context Header Allocation (Data Center)", December
	2014.	2014.

	[I-D.draft-quinn-sfc-nsh]	[I-D.draft-quinn-sfc-nsh]

	skipping to change at line 2477 ¶	skipping to change at page 56, line 12 ¶

	Email: michsmit@cisco.com	Email: michsmit@cisco.com
	Rakesh Reddy Kandula	Rakesh Reddy Kandula
	Cisco Systems	Cisco Systems
	Cessna Business Park, Kadubeesanahalli Village	Cessna Business Park, Kadubeesanahalli Village
	Sarjapur/Marathahalli Outer Ring Road	Sarjapur/Marathahalli Outer Ring Road
	Bangalore, Karnataka 560103	Bangalore, Karnataka 560103
	India	India

	Email: krreddy@cisco.com	Email: krreddy@cisco.com


		Syam
		Cisco Systems
		510 McCarthy Blvd.
		Milpitas, California 95035
		United States

		Email: syam1@cisco.com

End of changes. 16 change blocks.
	15 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/