draft-ietf-sigtran-addip-sctp-00.txt   draft-ietf-sigtran-addip-sctp-01.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Q. Xie Q. Xie
Motorola Motorola
M. Tuexen M. Tuexen
Siemens AG Siemens AG
I. Rytina I. Rytina
Ericsson Ericsson
expires in six months February 2, 2001 expires in six months February 23, 2001
SCTP Dynamic Addition of IP addresses SCTP Dynamic Addition of IP addresses
<draft-ietf-sigtran-addip-sctp-00.txt> <draft-ietf-sigtran-addip-sctp-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its areas, working documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 1, line 50 skipping to change at page 1, line 50
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction............................................... 2 1. Introduction............................................... 2
2. Conventions................................................ 2 2. Conventions................................................ 2
3. New Reliable Request/Acknowledgement Parameters............ 2 3. New Reliable Request/Acknowledgement Parameters............ 2
3.1 New REL-REQ Parameters.................................... 2 3.1 New REL-REQ Parameters.................................... 2
3.1.1 Add IP Address.......................................... 3 3.1.1 Add IP Address.......................................... 3
3.1.2 Delete IP Address....................................... 3 3.1.2 Delete IP Address....................................... 3
3.1.3 Set Primary IP Address.................................. 4 3.1.3 Set Primary IP Address.................................. 4
3.2 New REL-ACK Parameters.................................... 4 3.2 New REL-ACK Parameters.................................... 4
3.2.1 Error Cause: Request to Delete Last IP Address.......... 4 3.2.1 Error Cause: Request to Delete Last IP Address.......... 5
3.2.2 Error Cause: Operation Refused due to Resource Shortage. 5 3.2.2 Error Cause: Operation Refused due to Resource Shortage. 5
3.2.3 Error Cause: Request to Delete Source IP Address........ 6 3.2.3 Error Cause: Request to Delete Source IP Address........ 6
3.3 New Error Causes.......................................... 6 3.3 New Error Causes.......................................... 6
3.3.1 Request to delete last IP address....................... 6 3.3.1 Request to delete last IP address....................... 6
4. Procedures................................................. 6 4. Procedures................................................. 6
4.1 IP address addition and deletion.......................... 6 4.1 IP address addition and deletion.......................... 6
4.2 Setting of the Primary Address............................ 9 4.2 Setting of the Primary Address............................ 9
5. Security Considerations.................................... 9 5. Security Considerations.................................... 9
6. IANA considerations........................................10 6. IANA considerations........................................10
7. Authors' Addresses.........................................10 7. Authors' Addresses.........................................10
8. References.................................................10 8. References.................................................11
1. Introduction 1. Introduction
Taking advantage of the extensibility of SCTP, and the generic Taking advantage of the extensibility of SCTP, and the generic
method for transmitting reliable SCTP control chunks [RELREQ], method for transmitting reliable SCTP control chunks [RELREQ],
this document introduces a use of the reliable control chunk, this document introduces a use of the reliable control chunk,
to allow an existing SCTP association to add or delete IP addresses to allow an existing SCTP association to add or delete IP addresses
without the currently required restart of the association. without the currently required restart of the association.
This enables SCTP to have dynamic IP addresses added and subtracted This enables SCTP to have dynamic IP addresses added and subtracted
skipping to change at page 2, line 46 skipping to change at page 2, line 46
This section describes the addition of three new REL-REQ Parameters This section describes the addition of three new REL-REQ Parameters
to allow for the dynamic addition, deletion and setting of the to allow for the dynamic addition, deletion and setting of the
primary, of IP addresses to an existing SCTP association. The format primary, of IP addresses to an existing SCTP association. The format
of these REL-REQ parameters within the Reliable Request Chunk is of these REL-REQ parameters within the Reliable Request Chunk is
descibed in [REL-REQ]. We also describe a REL-ACK parameter that is descibed in [REL-REQ]. We also describe a REL-ACK parameter that is
carried to communicate errors or rejections of REL-REQ parameters. carried to communicate errors or rejections of REL-REQ parameters.
3.1 New REL-REQ Parameters 3.1 New REL-REQ Parameters
The two new REL-REQ Parameters added follow the format defined in The three new REL-REQ Parameters added follow the format defined in
[REL-REQ] section 3.1.1. Table 2 describes the two new REL-REQ [REL-REQ] section 3.1.1. Table 2 describes the three new REL-REQ
Parameters. Parameters.
REL-REQ Parameter Type Value REL-REQ Parameter Type Value
------------------------------------------------- -------------------------------------------------
Add IP Address 49153 (0xC001) Add IP Address 49153 (0xC001)
Delete IP Address 49154 (0xC002) Delete IP Address 49154 (0xC002)
Set Primary Address 49159 (0xC007) Set Primary Address 49159 (0xC007)
Table 1: REL-REQ Parameters Table 1: REL-REQ Parameters
3.1.1 Add IP Address 3.1.1 Add IP Address
skipping to change at page 3, line 19 skipping to change at page 3, line 19
| Type = 49153 | Length = Variable | | Type = 49153 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described This field contains an IPv4 or IPv6 address parameter as described
in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this
parameter. It informs the receiver that the Address specified is to parameter. It informs the receiver that the Address specified is to
be added to the existing association. be added to the existing association. The sender of this request
MUST NOT attempt to add an address type that is not supported by
its peer.
An example TLV adding the IPv4 address 10.1.1.1 to an existing An example TLV adding the IPv4 address 10.1.1.1 to an existing
association would look as follows: association would look as follows:
+--------------------------------+ +--------------------------------+
| Type=49153 | Length = 12 | | Type=49153 | Length = 12 |
+--------------------------------+ +--------------------------------+
| Type=5 | Length = 8 | | Type=5 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0a010101 | | Value=0x0a010101 |
skipping to change at page 4, line 41 skipping to change at page 4, line 47
+--------------------------------+ +--------------------------------+
| Type=5 | Length = 8 | | Type=5 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0a010101 | | Value=0x0a010101 |
+----------------+---------------+ +----------------+---------------+
3.2 New REL-ACK Parameters 3.2 New REL-ACK Parameters
Three new Error Causes are added to the SCTP Operational Errors, Three new Error Causes are added to the SCTP Operational Errors,
primarily for use as part of the REL-REQ Parameter Error in the primarily for use as part of the REL-REQ Parameter Error in the
REL-ACK (as outlined in [REL-REQ] section 3.1.2), but may be also be REL-ACK (as outlined in [REL-REQ] section 3.1.2).
used with an Operational Error or an Abort (as defined in RFC2960).
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
11 Request to delete last IP address. 11 Request to delete last IP address.
12 Operation Refused due to resource shortage. 12 Operation Refused due to resource shortage.
13 Request to delete source IP address. 13 Request to delete source IP address.
3.2.1 Error Cause: Request to Delete Last IP Address 3.2.1 Error Cause: Request to Delete Last IP Address
Cause of error Cause of error
--------------- ---------------
Request to delete last IP address: The receiver of this error sent a Request to delete last IP address: The receiver of this error sent a
request to delete the last IP address from its association with its request to delete the last IP address from its association with its
peer. This error indicates that the request is rejected. peer. This error indicates that the request is rejected.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=var | | Cause Code=11 | Cause Length=var |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Address Parameter / \ TLV-Copied-From-REL-REQ /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example of a failed delete in an Error Cause TLV would look as An example of a failed delete in an Error Cause TLV would look as
follows in the response REL-ACK message: follows in the response REL-ACK message:
+--------------------------------+ +--------------------------------+
| Type = 0xC005 | Length = 20 | | Type = 0xC005 | Length = 20 |
+--------------------------------+ +--------------------------------+
| Cause=11 | Length = 16 | | Cause=11 | Length = 16 |
skipping to change at page 6, line 19 skipping to change at page 6, line 20
Cause of error Cause of error
--------------- ---------------
Request to delete source IP address: The receiver of this error sent Request to delete source IP address: The receiver of this error sent
a request to delete the source IP address of the REL-REQ a request to delete the source IP address of the REL-REQ
message. This error indicates that the request is rejected. message. This error indicates that the request is rejected.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=VAR | | Cause Code=13 | Cause Length=VAR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Address Parameter / \ TLV-Copied-From-REL-REQ /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example of a failed delete in an Error Cause TLV would look as An example of a failed delete in an Error Cause TLV would look as
follows in the response REL-ACK message: follows in the response REL-ACK message:
+--------------------------------+ +--------------------------------+
| Type = 0xC005 | Length = 20 | | Type = 0xC005 | Length = 20 |
+--------------------------------+ +--------------------------------+
| Cause=13 | Length = 16 | | Cause=13 | Length = 16 |
skipping to change at page 7, line 6 skipping to change at page 7, line 7
D1) When adding an IP address to an association, the IP address is D1) When adding an IP address to an association, the IP address is
NOT considered fully added to the association until the REL-ACK NOT considered fully added to the association until the REL-ACK
arrives. This means that until such time as the REL-REQ arrives. This means that until such time as the REL-REQ
containing the add is acknowledged the sender MUST NOT use the containing the add is acknowledged the sender MUST NOT use the
new IP address as a source for ANY SCTP packet. new IP address as a source for ANY SCTP packet.
D2) After the REL-ACK of an IP address add arrives, the endpoint MAY D2) After the REL-ACK of an IP address add arrives, the endpoint MAY
begin using the added IP address as a source address. begin using the added IP address as a source address.
D3) If an endpoint receives an Error Cause TLV indicating that the D3) If an endpoint receives an Error Cause TLV indicating that the
IP address Add or IP address Deletion REL-REQ parameters were IP address Add, IP address Deletion, or Set Primary IP Address
not understood, the endpoint MUST consider the operation failed REL-REQ parameters was not understood, the endpoint MUST
and MUST NOT attempt to send any subsequent Add or Delete consider the operation failed and MUST NOT attempt to
requests to the peer. send any subsequent Add, Delete or Set Primary requests to
the peer.
D4) When deleting an IP address from an association, the IP address D4) When deleting an IP address from an association, the IP address
MUST be considered part of the association until the REL-ACK MUST be considered a valid source address for DATA chunks
arrives. This means that any datagrams that arrive before the until the REL-ACK arrives. This means that any datagrams that
REL-ACK destined to the IP address being deleted MUST be arrive before the REL-ACK destined to the IP address being
considered part of the current association. deleted MUST be considered part of the current association.
One special consideration is that ABORT chunks arriving destined
to the IP address being deleted MUST be ignored (see Section
4.1 for futher details).
D5) An endpoint MUST NOT delete its last IP address from an D5) An endpoint MUST NOT delete its last IP address from an
association. In other words if an endpoint is NOT multi-homed it association. In other words if an endpoint is NOT multi-homed it
MUST NOT use the delete IP address. Or if an endpoint sends MUST NOT use the delete IP address. Or if an endpoint sends
multiple requests to delete IP addresses it MUST NOT delete all multiple requests to delete IP addresses it MUST NOT delete all
of the IP addresses that the peer has listed for the requester. of the IP addresses that the peer has listed for the requester.
D6) An endpoint MUST NOT use the source address (of the IP packet D6) An endpoint MUST NOT use the source address (of the IP packet
containing the SCTP packet) for a REL-REQ to delete an IP containing the SCTP packet) for a REL-REQ to delete an IP
address from the address being deleted. address from the address being deleted.
D7) If a request is received to delete the last IP address of a peer D7) If a request is received to delete the last IP address of a peer
endpoint, the receiver MUST send an Error Cause TLV with the endpoint, the receiver MUST send an Error Cause TLV with the
error cause set to the new error code 'Request to delete last IP error cause set to the new error code 'Request to delete last IP
address'. The requested delete MUST NOT be performed or acted address'. The requested delete MUST NOT be performed or acted
upon, other than to send the Operational Error. upon, other than to send the REL-ACK.
D8) If a request is received to delete an IP address which is also D8) If a request is received to delete an IP address which is also
the source address of the IP packet which contained the REL-REQ the source address of the IP packet which contained the REL-REQ
chunk, the receiver MUST reject this request. To reject the chunk, the receiver MUST reject this request. To reject the
request the receiver MUST send a Error Cause TLV set to the new request the receiver MUST send a Error Cause TLV set to the new
error code "Request to Delete Source IP Address" (unless Rule D5 error code "Request to Delete Source IP Address" (unless Rule D5
has also been violated, in which case the error code 'Request to has also been violated, in which case the error code 'Request to
delete last IP address' is sent). delete last IP address' is sent).
D9) After the REL-ACK of an IP address deletion arrives, the D9) After the REL-ACK of an IP address deletion arrives, the
skipping to change at page 8, line 12 skipping to change at page 8, line 20
D12) When an endpoint receiving a REL-REQ to add an IP address sends D12) When an endpoint receiving a REL-REQ to add an IP address sends
an 'Out of Resource' in its response, it MUST also fail any an 'Out of Resource' in its response, it MUST also fail any
subsequent add or delete requests bundled in the REL-REQ. The subsequent add or delete requests bundled in the REL-REQ. The
receiver MUST NOT reject an ADD and then accept a subsequent receiver MUST NOT reject an ADD and then accept a subsequent
DELETE of an IP address in the same REL-REQ chunk. In other DELETE of an IP address in the same REL-REQ chunk. In other
words, once a receiver begins failing any ADD or DELETE request, words, once a receiver begins failing any ADD or DELETE request,
it must fail all subsequent ADD or DELETE requests contained in it must fail all subsequent ADD or DELETE requests contained in
that single REL-REQ. that single REL-REQ.
D13) When an endpoint receives a request to delete an IP address that
is the current primary address, it is an implementation decision
as to how that endpoint chooses the new primary address.
During the time interval between sending out the REL-REQ and During the time interval between sending out the REL-REQ and
receiving the REL-ACK it MAY be possible to receive DATA chunks out receiving the REL-ACK it MAY be possible to receive DATA chunks out
of order. The following examples illustrate these problems: of order. The following examples illustrate these problems:
Endpoint-A Endpoint-Z Endpoint-A Endpoint-Z
---------- ---------- ---------- ----------
REL-REQ[Add-IP:X]------------------------------> REL-REQ[Add-IP:X]------------------------------>
/--REL-ACK /--REL-ACK
/ /
/--------/---New DATA: /--------/---New DATA:
skipping to change at page 9, line 14 skipping to change at page 9, line 23
For the DELETE case, an endpoint MAY respond to the late arriving DATA For the DELETE case, an endpoint MAY respond to the late arriving DATA
packet as an OOTB datagram or it MAY hold the deleting IP address for a packet as an OOTB datagram or it MAY hold the deleting IP address for a
small period of time as still valid. If it treats the DATA packet as small period of time as still valid. If it treats the DATA packet as
an OOTB the peer will silently discard the ABORT (since by the time an OOTB the peer will silently discard the ABORT (since by the time
the ABORT is sent the peer will have removed the IP address from this the ABORT is sent the peer will have removed the IP address from this
association). If the endpoint elects to hold the IP address valid for association). If the endpoint elects to hold the IP address valid for
a period of time, it MUST NOT hold it valid longer than 2 RTO a period of time, it MUST NOT hold it valid longer than 2 RTO
intervals for the destination being removed. intervals for the destination being removed.
Another case worth mentioning is illustrated below:
Endpoint-A Endpoint-Z
---------- ----------
New DATA:------------\
Source IP:X \
\
REL-REQ[DEL-IP:X]-------\------------------>
\ /---------REL-ACK
\ /
\----/-----------> OOTB
(Ignored ----------------------/-------------ABORT
by rule D4) /
<---------------------/
For this case, during the deletion of an IP address, an
Abort MUST be ignored if the destination address of the
Abort message is that of the destination being deleted.
4.2 Setting of the primary address 4.2 Setting of the primary address
A sender of this option may elect to send this combined with A sender of this option may elect to send this combined with
a deletion request for an address. A sender MUST only send a deletion request for an address. A sender MUST only send
a set primary request to an address that is considered a set primary request to an address that is considered
part of the association. In other words a sender MUST NOT part of the association. In other words a sender MUST NOT
bundle a set primary with an add of a new IP address unless bundle a set primary with an add of a new IP address unless
the add request is to be processed BEFORE the set primary. the add request is to be processed BEFORE the set primary.
The request to set an address as the primary path is an option the The request to set an address as the primary path is an option the
receiver MAY perform. It is considered a hint to the receiver of the receiver MAY perform. It is considered a hint to the receiver of the
best destination address to use in sending SCTP packets (in the best destination address to use in sending SCTP packets (in the
requestors view). It is possible that the receiver may have other requestors view). It is possible that the receiver may have other
knowledge that it may act upon and NOT set the specified address as knowledge that it may act upon and NOT set the specified address as
primary. If a request arrives that asks the receiver to set an primary. If a request arrives that asks the receiver to set an
address as primary that does not exist, the receiver should NOT 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 reliable chunk passing mechanism itself does not add any security
considerations other than those addressed by the base level SCTP
protocol. However each new extension MAY result in new security
threats and each extension SHOULD make appropriate consideration of
these threats.
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 provide an additional mechanism by which existing associations can
be hijacked. Where the attacker is able to intercept and or alter be hijacked. Where the attacker is able to intercept and or alter
the packets sent and received in an association the use of this the packets sent and received in an association the use of this
feature MAY increase the ease at which an association may be feature MAY increase the ease at which an association may be
overtaken. This threat SHOULD be considered when deploying a version overtaken. This threat SHOULD be considered when deploying a version
of SCTP that use this feature. The IP Authentication Header of SCTP that use this feature. The IP Authentication Header
[RFC2402] SHOULD be used when the threat environment requires [RFC2402] SHOULD be used when the threat environment requires
stronger integrity protections, but does not require stronger integrity protections, but does not require
confidentiality. It should be noted that in the base SCTP confidentiality. It should be noted that in the base SCTP
specification [RFC2960], if an attacker is able to intercept and or specification [RFC2960], if an attacker is able to intercept and or
alter packets, even without this feature it is possible to hijack an alter packets, even without this feature it is possible to hijack an
existing association, please refer to Section 11 of RFC2960. existing association, please refer to Section 11 of RFC2960.
6. IANA considerations 6. IANA considerations
Two REL-REQ Parmeter Types and hree new SCTP Error Causes are Three REL-REQ Parmeter Types and three new SCTP Error Causes are
being defined within this document. being defined within this document.
7. Authors' Addresses 7. Authors' Addresses
Randall R. Stewart Tel: +1-815-477-2127 Randall R. Stewart Tel: +1-815-477-2127
Cisco Systems, Inc. EMail: rrs@cisco.com Cisco Systems, Inc. EMail: rrs@cisco.com
8745 W. Higgins Road, Suite 200 8745 W. Higgins Road, Suite 200
Chicago, Ill 60631 Chicago, Ill 60631
USA USA
 End of changes. 

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