< 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/ |