draft-ietf-tsvwg-addip-sctp-18.txt   draft-ietf-tsvwg-addip-sctp-19.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Q. Xie Intended status: Standards Track Q. Xie
Expires: August 30, 2007 Motorola, Inc. Expires: September 21, 2007 Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
S. Maruyama S. Maruyama
M. Kozuka M. Kozuka
Kyoto University Kyoto University
February 26, 2007 March 20, 2007
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-18.txt draft-ietf-tsvwg-addip-sctp-19.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007. This Internet-Draft will expire on September 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes extensions to the Stream Control Transmission This document describes extensions to the Stream Control Transmission
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
address information on an existing association. address information on an existing association.
skipping to change at page 2, line 43 skipping to change at page 2, line 43
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18 5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18
5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 20 5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 20
5.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21 5.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21
5.3. General rules for address manipulation . . . . . . . . . . 23 5.3. General rules for address manipulation . . . . . . . . . . 23
5.3.1. A special case for OOTB ABORT Chunks . . . . . . . . . 27 5.3.1. A special case for OOTB ABORT Chunks . . . . . . . . . 27
5.3.2. A special case for changing an address. . . . . . . . 27 5.3.2. A special case for changing an address. . . . . . . . 27
5.4. Setting of the primary address . . . . . . . . . . . . . . 28 5.4. Setting of the primary address . . . . . . . . . . . . . . 28
5.5. Bundling of multiple ASCONFs . . . . . . . . . . . . . . . 28 5.5. Bundling of multiple ASCONFs . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Normative References . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 32 Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 32
A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 32 A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 32
A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 32 A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 32
A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 33 A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 33
A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 34 A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 34
A.5. Rules for address manipulation . . . . . . . . . . . . . . 34 A.5. Rules for address manipulation . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
skipping to change at page 5, line 24 skipping to change at page 5, line 24
programming the comparison of such values. When referring to ASCONF programming the comparison of such values. When referring to ASCONF
Sequence Numbers, the symbol "=<" means "less than or equal"(modulo Sequence Numbers, the symbol "=<" means "less than or equal"(modulo
2**32). 2**32).
Comparisons and arithmetic on ASCONF sequence numbers in this Comparisons and arithmetic on ASCONF sequence numbers in this
document SHOULD use Serial Number Arithmetic as defined in [RFC1982] document SHOULD use Serial Number Arithmetic as defined in [RFC1982]
where SERIAL_BITS = 32. where SERIAL_BITS = 32.
ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. That ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. That
is, the next ASCONF Sequence Number an ASCONF chunk MUST use after is, the next ASCONF Sequence Number an ASCONF chunk MUST use after
transmitting ASCONF Sequence Number = 2*32 - 1 is TSN = 0. transmitting ASCONF Sequence Number = 2*32 - 1 is 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document uses normal All other arithmetic and comparisons in this document uses normal
arithmetic. arithmetic.
4. Additional Chunks and Parameters 4. Additional Chunks and Parameters
This section describes the addition of two new chunks and, seven new This section describes the addition of two new chunks and, seven new
parameters to allow: parameters to allow:
skipping to change at page 7, line 17 skipping to change at page 7, line 17
MAY lookup the association by other information provided in the MAY lookup the association by other information provided in the
packet. This parameter MUST be present in every ASCONF message i.e. packet. This parameter MUST be present in every ASCONF message i.e.
it is a mandatory TLV parameter. it is a mandatory TLV parameter.
Note: the host name address MUST NOT be sent and MUST be ignored if Note: the host name address MUST NOT be sent and MUST be ignored if
received in any ASCONF message. received in any ASCONF message.
It should be noted that the ASCONF Chunk format requires the receiver It should be noted that the ASCONF Chunk format requires the receiver
to report to the sender if it does not understand the ASCONF Chunk. to report to the sender if it does not understand the ASCONF Chunk.
This is accomplished by setting the upper bits in the chunk type as This is accomplished by setting the upper bits in the chunk type as
described in RFC2960 [RFC2960] section 3.2. Note: that the upper two described in RFC2960 [RFC2960] section 3.2. Note that the upper two
bits in the ASCONF Chunk are set to one. As defined in RFC2960 bits in the ASCONF Chunk are set to one. As defined in RFC2960
[RFC2960] section 3.2, when setting these upper bits in this manner [RFC2960] section 3.2, when setting these upper bits in this manner
the receiver that does not understand this chunk MUST skip the chunk the receiver that does not understand this chunk MUST skip the chunk
and continue processing, and report in an Operation Error Chunk using and continue processing, and report in an Operation Error Chunk using
the 'Unrecognized Chunk Type' cause of error. This will NOT abort the 'Unrecognized Chunk Type' cause of error. This will NOT abort
the association but indicates to the sender that it MUST not send any the association but indicates to the sender that it MUST not send any
further ASCONF chunks. further ASCONF chunks.
ASCONF Parameter: TLV format ASCONF Parameter: TLV format
skipping to change at page 8, line 39 skipping to change at page 8, line 39
The ASCONF Parameter Response is used in the ASCONF-ACK to report The ASCONF Parameter Response is used in the ASCONF-ACK to report
status of ASCONF processing. By default, if a responding endpoint status of ASCONF processing. By default, if a responding endpoint
does not include any Error Cause, a success is indicated. Thus a does not include any Error Cause, a success is indicated. Thus a
sender of an ASCONF-ACK MAY indicate complete success of all TLVs in sender of an ASCONF-ACK MAY indicate complete success of all TLVs in
an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length
(set to 8) and the Serial Number. (set to 8) and the Serial Number.
4.2. New Parameter Types 4.2. New Parameter Types
The seven new parameters added follow the format defined in section The seven new parameters added follow the format defined in section
3.2.1 of RFC2960 [RFC2960]. Table 2, 3 and 4 describes the 3.2.1 of RFC2960 [RFC2960]. Table 2, 3 and 4 describe the
parameters. parameters.
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
Set Primary Address 0xC004 Set Primary Address 0xC004
Adaptation Layer Indication 0xC006 Adaptation Layer Indication 0xC006
Table 2: Parameters that can be used in INIT/INIT-ACK chunk Table 2: Parameters that can be used in INIT/INIT-ACK chunk
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
skipping to change at page 14, line 20 skipping to change at page 14, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC006 | Length = 8 | | Type =0xC006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Code point | | Adaptation Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is specified for the communication of peer upper layer This parameter is specified for the communication of peer upper layer
protocols. It is envisioned to be used for flow control and other protocols. It is envisioned to be used for flow control and other
adaptation layers that require an indication to be carried in the adaptation layers that require an indication to be carried in the
INIT and INIT-ACK. Each adaptation layer that is defined that wishes INIT and INIT-ACK. Each adaptation layer that is defined that wishes
to use this parameter MUST specify a an adaptation code point in an to use this parameter MUST specify an adaptation code point in an
appropriate RFC defining its use and meaning. This parameter SHOULD appropriate RFC defining its use and meaning. This parameter SHOULD
NOT be examined by the receiving SCTP implementation and should be NOT be examined by the receiving SCTP implementation and should be
passed opaquely to the upper layer protocol. passed opaquely to the upper layer protocol.
Note: that this parameter is not used in either the addition or Note: this parameter is not used in either the addition or deletion
deletion of addresses but is for the convience of the upper layer. of addresses but is for the convenience of the upper layer. This
This document includes this parameter to minimize the number of SCTP document includes this parameter to minimize the number of SCTP
documents. documents.
Valid Chunk Appearance Valid Chunk Appearance
The Adaptation Layer Indication parameter may appear in INIT or INIT- The Adaptation Layer Indication parameter may appear in INIT or INIT-
ACK chunk and SHOULD be passed to the receivers upper layer protocol ACK chunk and SHOULD be passed to the receivers upper layer protocol
based upon the upper layer protocol configuration of the SCTP stack. based upon the upper layer protocol configuration of the SCTP stack.
This parameter MUST NOT be sent in any other chunks and if it is This parameter MUST NOT be sent in any other chunks and if it is
received in another chunk it MUST be ignored. received in another chunk it MUST be ignored.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED and state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED and
SHUTDOWN-SENT. SHUTDOWN-SENT.
C5) An ASCONF Chunk and an ASCONF-ACK Chunk SHOULD not be larger C5) An ASCONF Chunk and an ASCONF-ACK Chunk SHOULD not be larger
than the path MTU. If the path MTU is unknown, then the path MTU than the path MTU. If the path MTU is unknown, then the path MTU
should be set to a minimal path MTU. The minimum PMTU depends on should be set to a minimal path MTU. The minimum PMTU depends on
the IP version used for transmission, and is the lesser of 576 the IP version used for transmission, and is the lesser of 576
octets and the first-hop MTU for IPv4 RFC1122 [RFC1122] and 1280 octets and the first-hop MTU for IPv4 RFC1122 [RFC1122] and 1280
octets for IPv6 RFC2460 [RFC2460]. octets for IPv6 RFC2460 [RFC2460].
A ASCONF sender without these restrictions could possibly flood the An ASCONF sender without these restrictions could possibly flood the
network with a large number of seperate address change operations network with a large number of separate address change operations
thus causing network congestion. thus causing network congestion.
If the sender of an ASCONF Chunk receives an Operational Error If the sender of an ASCONF Chunk receives an Operational Error
indicating that the ASCONF Chunk type is not understood, then the indicating that the ASCONF Chunk type is not understood, then the
sender MUST NOT send subsequent ASCONF Chunks to the peer. The sender MUST NOT send subsequent ASCONF Chunks to the peer. The
endpoint should also inform the upper layer application that the peer endpoint should also inform the upper layer application that the peer
endpoint does not support any of the extensions detailed in this endpoint does not support any of the extensions detailed in this
document. document.
5.2. Upon reception of an ASCONF Chunk. 5.2. Upon reception of an ASCONF Chunk.
skipping to change at page 29, line 22 skipping to change at page 29, line 22
The addition and or deletion of an IP address to an existing The addition and or deletion of an IP address to an existing
association does provide an additional mechanism by which existing association does provide an additional mechanism by which existing
associations can be hijacked. Therefore this document requires the associations can be hijacked. Therefore this document requires the
use of the authentication mechanism defined in SCTP-AUTH use of the authentication mechanism defined in SCTP-AUTH
[I-D.ietf-tsvwg-sctp-auth] to limit the ability of an attacker to [I-D.ietf-tsvwg-sctp-auth] to limit the ability of an attacker to
hijack an association. hijack an association.
Hijacking an association by using the addition and deletion of an IP Hijacking an association by using the addition and deletion of an IP
address is only possible for an attacker who is able to intercept the address is only possible for an attacker who is able to intercept the
initial two packets of the association setup when the SCTP-AUTH initial two packets of the association setup when the SCTP-AUTH
extension is used without pre-shared keys.. If such a threat is extension is used without pre-shared keys. If such a threat is
considered a possibility, then the SCTP-AUTH considered a possibility, then the SCTP-AUTH
[I-D.ietf-tsvwg-sctp-auth] extension MUST be used with a [I-D.ietf-tsvwg-sctp-auth] extension MUST be used with a
preconfigured shared end-point pair key to mitigate this threat. For preconfigured shared end-point pair key to mitigate this threat. For
a more detailed analysis see SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. a more detailed analysis see SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].
When using a wildcard address for adding or deleting an address the
source address of the packet is used. This address is not protected
by SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] and an attacker can therefore
intercept such a packet and modfiy the source address.
If an SCTP endpoint that supports this extension receives an INIT If an SCTP endpoint that supports this extension receives an INIT
that indicates that the peer supports the ASCONF extension but does that indicates that the peer supports the ASCONF extension but does
NOT support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] extension, the NOT support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] extension, the
receiver of such an INIT MUST send an ABORT in response to such an receiver of such an INIT MUST send an ABORT in response to such an
INIT. Note: that an implementation is allowed to silently discard INIT. Note: that an implementation is allowed to silently discard
such an INIT as an option as well but under NO circumstance is an such an INIT as an option as well but under NO circumstance is an
implementation allowed to proceed with the association setup by implementation allowed to proceed with the association setup by
sending an INIT-ACK in response. sending an INIT-ACK in response.
An implementation that receives an INIT-ACK that indicates that the An implementation that receives an INIT-ACK that indicates that the
skipping to change at page 31, line 34 skipping to change at page 31, line 34
formation of this draft. formation of this draft.
The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter
Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose, Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose,
Chip Sharp, and Irene Ruengeler for their invaluable comments. Chip Sharp, and Irene Ruengeler for their invaluable comments.
The authors would also like to give special mention to Maria-Carmen The authors would also like to give special mention to Maria-Carmen
Belinchon and Ian Rytina for there early contributions to this Belinchon and Ian Rytina for there early contributions to this
document and their thoughtful comments. document and their thoughtful comments.
9. References 9. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 32, line 14 skipping to change at page 32, line 14
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[I-D.ietf-tsvwg-sctp-auth] [I-D.ietf-tsvwg-sctp-auth]
Tuexen, M., "Authenticated Chunks for Stream Control Tuexen, M., "Authenticated Chunks for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctp-auth-07 (work in progress), draft-ietf-tsvwg-sctp-auth-08 (work in progress),
January 2007. February 2007.
Appendix A. Abstract Address Handling Appendix A. Abstract Address Handling
A.1. General remarks A.1. General remarks
This appendix is non-normative. It is present to give the reader a This appendix is non-normative. It is present to give the reader a
concise mathematical definition of an SCTP endpoint. The following concise mathematical definition of an SCTP endpoint. The following
text provides a working definition of the endpoint notion to discuss text provides a working definition of the endpoint notion to discuss
address reconfiguration. It is not intended to restrict address reconfiguration. It is not intended to restrict
implementations in any way, its goal is to provide a set of implementations in any way, its goal is to provide a set of
 End of changes. 16 change blocks. 
19 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/