< 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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/