draft-ietf-tsvwg-addip-sctp-10.txt   draft-ietf-tsvwg-addip-sctp-11.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: July 31, 2005 Cisco Systems, Inc. Expires: August 24, 2005 Cisco Systems, Inc.
Q. Xie Q. Xie
Motorola, Inc. Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
P. Conrad P. Conrad
University of Delaware University of Delaware
January 28, 2005 February 20, 2005
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-10.txt draft-ietf-tsvwg-addip-sctp-11.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 July 31, 2005. This Internet-Draft will expire on August 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 6, line 48 skipping to change at page 6, line 48
continue processing, but report in an Operation Error Chunk using the continue processing, but report in an Operation Error Chunk using the
'Unrecognized Chunk Type' cause of error. 'Unrecognized Chunk Type' cause of error.
3.1.1 Address Configuration Change Chunk (ASCONF) 3.1.1 Address Configuration Change Chunk (ASCONF)
This chunk is used to communicate to the remote endpoint one of the This chunk is used to communicate to the remote endpoint one of the
configuration change requests that MUST be acknowledged. The configuration change requests that MUST be acknowledged. The
information carried in the ASCONF Chunk uses the form of a information carried in the ASCONF Chunk uses the form of a
Type-Length-Value (TLV), as described in "3.2.1 Type-Length-Value (TLV), as described in "3.2.1
Optional/Variable-length Parameter Format" in RFC2960 [6], for all Optional/Variable-length Parameter Format" in RFC2960 [6], for all
variable parameters. variable parameters. This chunk MUST be sent in an authenticated way
by using the mechanism defined in SCTP-AUTH [7]. If this chunk is
received unauthenticated it MUST be silently discarded as described
in SCTP-AUTH [7].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC1 | Chunk Flags | Chunk Length | | Type = 0xC1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 52 skipping to change at page 7, line 52
ASCONF Parameter: TLV format ASCONF Parameter: TLV format
Each Address configuration change is represented by a TLV parameter Each Address configuration change is represented by a TLV parameter
as defined in Section 3.2. One or more requests may be present in an as defined in Section 3.2. One or more requests may be present in an
ASCONF Chunk. ASCONF Chunk.
3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) 3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK)
This chunk is used by the receiver of an ASCONF Chunk to acknowledge This chunk is used by the receiver of an ASCONF Chunk to acknowledge
the reception. It carries zero or more results for any ASCONF the reception. It carries zero or more results for any ASCONF
Parameters that were processed by the receiver. Parameters that were processed by the receiver. This chunk MUST be
sent in an authenticated way by using the mechanism defined in
SCTP-AUTH [7]. If this chunk is received unauthenticated it MUST be
silently discarded as described in SCTP-AUTH [7].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x80 | Chunk Flags | Chunk Length | | Type = 0x80 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#1 | | ASCONF Parameter Response#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 9 skipping to change at page 28, line 9
receiver SHOULD perform. It is considered advice to the receiver of receiver SHOULD perform. It is considered advice to the receiver of
the best destination address to use in sending SCTP packets (in the the best destination address to use in sending SCTP packets (in the
requesters view). If a request arrives that asks the receiver to set requesters view). If a request arrives that asks the receiver to set
an address as primary that does not exist, the receiver should NOT an address as primary that does not exist, the receiver should NOT
honor the request, leaving its existing primary address unchanged. honor the request, leaving its existing primary address unchanged.
5. Security Considerations 5. Security Considerations
The ADD/DELETE of an IP address to an existing association does The ADD/DELETE of an IP address to an existing association does
provide an additional mechanism by which existing associations can be provide an additional mechanism by which existing associations can be
hijacked. Where the attacker is able to intercept and/or alter the hijacked.
packets sent and received in an association, the use of this feature
MAY increase the ease with which an association may be overtaken.
This threat SHOULD be considered when deploying a version of SCTP
that makes use of this feature. The IP Authentication Header RFC2402
[3] SHOULD be used when the threat environment requires stronger
integrity protections, but does not require confidentiality. It
should be noted that in the base SCTP specification RFC2960 [6], if
an attacker is able to intercept and or alter packets, even without
this feature it is possible to hijack an existing association; please
refer to Section 11 of RFC2960 [6].
Future versions of this document may require use of purpose built This document requires the use of the authentication mechanism
keys (pbk). A purpose built key mechanism assure that the endpoint defined in SCTP-AUTH [7] to limit the ability of an attacker to
adding or deleting IP addresses is most likely the same endpoint that hijack an association. Hijacking an association by using ADD/DELETE
the association started with aka the sender of the INIT or INIT-ACK. of an IP address is only possible for an attacker who is able to
intercept the association setup. However, if a preconfigured shared
end-point pair key is used this is not possible. For a more detailed
analysis see SCTP-AUTH [7].
6. IANA considerations 6. IANA considerations
This document defines the following new SCTP parameters, chunks and This document defines the following new SCTP parameters, chunks and
errors: errors:
o Two new chunk types, o Two new chunk types,
o Six parameter types, and o Six parameter types, and
o Three new SCTP error causes. o Three new SCTP error causes.
This document also defines a Adaption code point. The adaption code This document also defines a Adaption code point. The adaption code
point is a 32 bit interger that is assigned by IANA through an IETF point is a 32 bit integer that is assigned by IANA through an IETF
Consensus action as defined in RFC2434 [4]. Consensus action as defined in RFC2434 [4].
7. Acknowledgments 7. Acknowledgments
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,
and Chip Sharp for their invaluable comments. and Chip Sharp 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
skipping to change at page 30, line 35 skipping to change at page 30, line 35
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June [5] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999. 1999.
[6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[7] Tuexen, M., Stewart, R., Lei, P. and E. Rescorla, "Authenticated
Chunks for Stream Control Transmission Protocol (SCTP)",
Internet-Draft draft-tuexen-sctp-auth-chunk-03, February 2005.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/