Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
draft-ietf-tsvwg-addip-sctp-22

[Ballot discuss]
Sandy Murphy has performed an extensive review of this document for
the security directorate.  Please ensure these comments are considered
as Last Call comments by the editors.

-----

This document extends 2960bis by adding a mechanism that would allow an
endpoint in an sctp association to modify the list of addresses that are
to be considered part of its endpoint.  The draft defines new ASCONF and
ASCONF-ACK chunks.  The ASCONF chunk carries a list of configuration
requests, each of which has a serial number that is referred to in the
ASCONF-ACK responses.  The draft also specifies a mechanism to inform
the other endpoint on startup what extensions it supports -- a feature
that would also allow communication of other extensions besides this
one, of course.  The document also specifies another new feature that
would allow communication of an opaque value to the adaptation layer,
which is not concerned with modification of endpoint IP addresses and is
included in this document only to limit the number of sctp documents.

Adding a new IP address to an existing sctp connection would provide
opportunities to hijack an existing association, which is mentioned in
the security considerations section.  It also permits bombing a victim
with data, a threat mentioned in the threats draft.  The threat draft
concentrates on attacks from outside attackers.  However, there is also
the possibility that a fauly/misconfigured/subverted participant could
overwhelm a victim IP address by adding it to a connection.  This draft
mandates that a new authentication feature (specified in
draft-ietf-tsvwg-sctp-auth-08.txt ) be used that would prevent this
attack from outsiders.  The threats document points out that a new
HEARTBEAT feature (previously in RFC4460 but now included in
draft-ietf-tsvwg-2960bis-04.txt) that uses a random challenge and
response to verify any new address on a connection will limit this
attack (except for the amplification attack resulting from the
challenges).

This draft does not refer to the threats document, which it should.  In
particular, this document does not refer to the HEARTBEAT feature's
protection (and added vulnerability) against adding a victim's address
to an association.

This draft points out one remaining vulnerability - that an on-path
attacker could replay packets that result in adding the source IP
address of the packet even when the authentication mechanism is used,
because the headers are not protected.  If the "chunk" carrying the new
IP address uses the wild-card for the address parameter to add or delete
the address or set the primary address, the IP address of the packet is
used as the source.  But the IP header is not included in the new
authentication mechanism, so it is possible for even authenticated
chunks to be carried in a packet that has been modified with a spoofed
source address, resulting in a victim's IP address being added to an
association.  (I believe that the serial number included in the ASCONF
chunks defined in this document provide protection against replay.) This
draft's security considerations section mentions this, but makes no
comment or suggestion for a countermeasure or work-around.  The draft
should at least mention deployment scenarios where this would and would
not be a problem.

This draft requires that the new AUTH must be used to protect these new
chunks and that it must be used with a shared key (it is possible to use
the AUTH feature without a shared key).  RFC2960 and rfc2960bis both
mention using AH and ESP for protecting the sctp association.  The auth
draft and this draft do not mention why AH and ESP would not be
sufficient and why the new AUTH feature is preferable.  They do not say
if AH and AUTH can both be used.  It should.  Myself, I am not sure how
IPSec could be used to protect packets that are transmitted to one of a
number of different, changing endpoints (perhaps using a non-multicast
group mechanism?), so I can see why IPSec might present problems.  I can
see that IPSec or IPSec implementations might have difficulty in
associating an SA with an association between the endpoints (multiple
associations between endpoints seem to be possible).

The security considerations section does not discuss the new features
added to the INIT/INIT-ACK chunks -- set primary communication of
supported extensions and the adaptation layer opaque value.  It really
should, as the INIT/INIT-ACK chunks can not be protected by the AUTH
chunk.

This document refers to RFC2960 explicitly.  I do not know that the RFC
Editor can be counted on to review the document and replace all such
occurrences with the appropriate new RFC number when the rfc2960bis goes
forward.  All the section numbers I checked seemed to be the same in
RFC2960 and rfc2960bis, but I did not check the text in the sections.

Section 4.1.1 and the security consideration section say that the ASCONF
chunks must be authenticated as in the -auth- draft (using AUTH Chunks).
Does this mean that the CHUNKS parameter in the INIT MUST include the
ASCONF and ASCONF-ACK in the list of chunks that must be authenticated?
(Note: AUTH chunks protect all chunks that follow it in the sctp
packet.)

Section 4.2.3 depiction of the Error Cause Indication parameter to an
ASCONF-ACK says that the part of the value is "Error Cause(s) or Return
Info on Success."  The "Return Info on Success" is never described.
There is a separate parameter for "Success Indication."  Perhaps the
"Return Info on Success" is a typo?  If not, it should be described.

Section 4.2.4 describes the "Set Primary" parameter.  This parameter can
be carried in an ASCONF chunk or in the INIT and INIT-ACK.  I believe
that when carried in an INIT-ACK it indicates the sender's preference
for its own primary address, not a copy of the Set Primary parameter
from the INIT.  Perhaps that could be said.  Also, later text says that
the Set Primary SHOULD reference an "existing" address of the
association, which did not for me settle the question of whether the Set
Primary action does or does not at the same time add the address to the
association.

Section 4.2.7 says that the Supported Extensions parameter for the INIT
and INIT-ACK must list the ASCONF and ASCONF-ACK chunk types.  Since
this draft mandates the use of the new AUTH chunks, this section should
also say that the AUTH chunk type must be included in the INIT.  Note,
however, that the INIT and INIT-ACK chunk types can not be protected by
the AUTH chunks, so this list is not protected.  Modification of the
INIT/INIT-ACK chunks that resulted in a lack of AUTH chunks for received
ASCONF chunks would result in those chunks being dropped.  (I think
-- based on what the AUTH draft says.)  Receipt of the INIT/INIT-ACK
chunks that did not include ASCONF in the Supported Extensions is not
discussed, so I can not be sure whether the result of modifying the INIT
to remove mention of ASCONF would be a failure to use ASCONF or a
failure of the association.

Section 4.3 describes each new Error Cause.  Each Error Cause contains
the "ASCONF-Request Correlation ID."  The draft says that "The sender of
the ASCONF can use this same value in the ASCONF-ACK to find which
request the response is for."  And yet, each Error Cause in the
ASCONF-ACK repeats the complete request parameter.  If the complete
request parameter (correlation id + value) really needs to be repeated,
is there some check to ensure that the request parameter's value matches
the correlation id?

(Note here: the chunks are expressed as TLVs, carry parameters that are
themselves TLVs and the values sometimes have "parameters" and those are
sometimes expressed as TLVs.  So it requires very very careful reading
when the Error Cause is said to include "TLV-Copied-From-ASCONF."  The
example helps because it uses requests that appeared in previous
examples.)

In Section 5.1, the procedure says:

  A3)  If no SCTP packet with one or more ASCONF Chunk(s) is
      outstanding (un-acknowledged) with the remote peer, send the
      chunk.

  A4)  The sender MUST Start a T-4 RTO timer, using the RTO value of
      the selected destination address (normally the primary path; see
      RFC2960 [RFC2960] section 6.4 for details).


A4 is presumably only done if A3 resulted in the transmission of a
chunk.  If there is already an un-acknowledged SCTP packet carrying a
ASCONF chunk, presumably the new ASCONF chunk is queued for later
transmission.  The text here should be explicit, as this is the
procedure.

In step B4, it says "sequence number" when I think it means "serial
number."

Section 5.2 describes the procedure upon receipt of an ASCONF chunk.
Part of this procedure is associating the packet with the appropriate
association.  Part of that must also produce the association key for
checking the AUTH chunk.  But the verification of the AUTH chunk is not
mentioned in the procedure, although the verification of the
Verification Tag is mentioned.  It would be nice to say where the AUTH
verification occurs.

In D2-ext:

  D2-ext)  If more than one ASCONF Chunks are packed together, use the
      address found in the ASCONF Address Parameter TLV of the each of
      the subsequent ASCONF Chunks.

I think there are some extra words in the "of the each of the" part.

  E1)  If the value found in the serial number of the ASCONF Chunk is
      equal to the ('Peer-Serial-Number' + 1) and the Serial Number of
      the ASCONF Chunk is the first in the SCTP Packet,

  E1-ext  If the value found in the serial number of the ASCONF Chunk
      is equal to the ('Peer-Serial-Number' + 1) and the ASCONF chunk is
      NOT the first Serial Number in the SCTP packet


I am not sure what the serial number being the first in the packet or
the chunk is the first serial number in the packet.  I believe that this
means that the *chunk* is the first or not the first in the packet.  I
believe that "serial number" is a term used only in the ASCONF chunks,
but I have not reviewed all sctp documents.

Multiple ASCONF chunks are supposed to be placed in the packet in
increasing order of their serial numbers.  So the first ASCONF in the
received packet should have the least serial number.  But what if it
doesn't (the sender messes up)?  Is this text attempting to say that you
process the ASCONF chunks in the order they appear, whatever order their
serial numbers are in?  Or is it trying to say that you process the
ASCONF chunks in the order of their serial numbers, whatever order they
appear in the packet?

In Section 5.3.2:

  should attempt to use the address found in the Address Bytes field

"Address Bytes" I think is supposed to be "Address Parameter."

In Section 5.4:

  A sender of this option may elect to send this combined with a
  deletion or addition of an address.  A sender SHOULD only send a set
  primary request to an address that is already considered part of the
  association.  In other words if a sender combines a set primary with
  an add of a new IP address the set primary will be discarded unless
  the add request is to be processed BEFORE the set primary (i.e. it
  precedes the set primary).

Is the first "may elect" supposed to be "MAY elect", or is this a normal
"could possibly elect?"

The text says that a set primary "will be discarded", but that the
sender "SHOULD only send."  So is the "will be discarded" certain?  If
so, perhaps the text should say "MUST only send?"  If not, perhaps the
text should say "might be discarded?"

In the last paragraph of the section, change "should NOT" to "SHOULD
NOT."

Section 6:

  When using a wildcard address for adding or deleting an address the
  source address of the packet is used.

Or when setting the primary address.

In section 7, it makes many statements like "We recommend 0x80 but any
other available code point with the upper bit set is also acceptable."
If IANA should choose a different code point, will they edit the rest of
the draft where that value is mentioned?.  I ask because I don't know.

Section 8: replace "there" with "their" in both cases.

[Ballot discuss]
Sandy Murphy has performed an extensive review of this dopcument for
the security directorate.  Please ensure these comments are considered
as Last Call comments by the editors.

-----

This document extends 2960bis by adding a mechanism that would allow an
endpoint in an sctp association to modify the list of addresses that are
to be considered part of its endpoint.  The draft defines new ASCONF and
ASCONF-ACK chunks.  The ASCONF chunk carries a list of configuration
requests, each of which has a serial number that is referred to in the
ASCONF-ACK responses.  The draft also specifies a mechanism to inform
the other endpoint on startup what extensions it supports -- a feature
that would also allow communication of other extensions besides this
one, of course.  The document also specifies another new feature that
would allow communication of an opaque value to the adaptation layer,
which is not concerned with modification of endpoint IP addresses and is
included in this document only to limit the number of sctp documents.

Adding a new IP address to an existing sctp connection would provide
opportunities to hijack an existing association, which is mentioned in
the security considerations section.  It also permits bombing a victim
with data, a threat mentioned in the threats draft.  The threat draft
concentrates on attacks from outside attackers.  However, there is also
the possibility that a fauly/misconfigured/subverted participant could
overwhelm a victim IP address by adding it to a connection.  This draft
mandates that a new authentication feature (specified in
draft-ietf-tsvwg-sctp-auth-08.txt ) be used that would prevent this
attack from outsiders.  The threats document points out that a new
HEARTBEAT feature (previously in RFC4460 but now included in
draft-ietf-tsvwg-2960bis-04.txt) that uses a random challenge and
response to verify any new address on a connection will limit this
attack (except for the amplification attack resulting from the
challenges).

This draft does not refer to the threats document, which it should.  In
particular, this document does not refer to the HEARTBEAT feature's
protection (and added vulnerability) against adding a victim's address
to an association.

This draft points out one remaining vulnerability - that an on-path
attacker could replay packets that result in adding the source IP
address of the packet even when the authentication mechanism is used,
because the headers are not protected.  If the "chunk" carrying the new
IP address uses the wild-card for the address parameter to add or delete
the address or set the primary address, the IP address of the packet is
used as the source.  But the IP header is not included in the new
authentication mechanism, so it is possible for even authenticated
chunks to be carried in a packet that has been modified with a spoofed
source address, resulting in a victim's IP address being added to an
association.  (I believe that the serial number included in the ASCONF
chunks defined in this document provide protection against replay.) This
draft's security considerations section mentions this, but makes no
comment or suggestion for a countermeasure or work-around.  The draft
should at least mention deployment scenarios where this would and would
not be a problem.

This draft requires that the new AUTH must be used to protect these new
chunks and that it must be used with a shared key (it is possible to use
the AUTH feature without a shared key).  RFC2960 and rfc2960bis both
mention using AH and ESP for protecting the sctp association.  The auth
draft and this draft do not mention why AH and ESP would not be
sufficient and why the new AUTH feature is preferable.  They do not say
if AH and AUTH can both be used.  It should.  Myself, I am not sure how
IPSec could be used to protect packets that are transmitted to one of a
number of different, changing endpoints (perhaps using a non-multicast
group mechanism?), so I can see why IPSec might present problems.  I can
see that IPSec or IPSec implementations might have difficulty in
associating an SA with an association between the endpoints (multiple
associations between endpoints seem to be possible).

The security considerations section does not discuss the new features
added to the INIT/INIT-ACK chunks -- set primary communication of
supported extensions and the adaptation layer opaque value.  It really
should, as the INIT/INIT-ACK chunks can not be protected by the AUTH
chunk.

This document refers to RFC2960 explicitly.  I do not know that the RFC
Editor can be counted on to review the document and replace all such
occurrences with the appropriate new RFC number when the rfc2960bis goes
forward.  All the section numbers I checked seemed to be the same in
RFC2960 and rfc2960bis, but I did not check the text in the sections.

Section 4.1.1 and the security consideration section say that the ASCONF
chunks must be authenticated as in the -auth- draft (using AUTH Chunks).
Does this mean that the CHUNKS parameter in the INIT MUST include the
ASCONF and ASCONF-ACK in the list of chunks that must be authenticated?
(Note: AUTH chunks protect all chunks that follow it in the sctp
packet.)

Section 4.2.3 depiction of the Error Cause Indication parameter to an
ASCONF-ACK says that the part of the value is "Error Cause(s) or Return
Info on Success."  The "Return Info on Success" is never described.
There is a separate parameter for "Success Indication."  Perhaps the
"Return Info on Success" is a typo?  If not, it should be described.

Section 4.2.4 describes the "Set Primary" parameter.  This parameter can
be carried in an ASCONF chunk or in the INIT and INIT-ACK.  I believe
that when carried in an INIT-ACK it indicates the sender's preference
for its own primary address, not a copy of the Set Primary parameter
from the INIT.  Perhaps that could be said.  Also, later text says that
the Set Primary SHOULD reference an "existing" address of the
association, which did not for me settle the question of whether the Set
Primary action does or does not at the same time add the address to the
association.

Section 4.2.7 says that the Supported Extensions parameter for the INIT
and INIT-ACK must list the ASCONF and ASCONF-ACK chunk types.  Since
this draft mandates the use of the new AUTH chunks, this section should
also say that the AUTH chunk type must be included in the INIT.  Note,
however, that the INIT and INIT-ACK chunk types can not be protected by
the AUTH chunks, so this list is not protected.  Modification of the
INIT/INIT-ACK chunks that resulted in a lack of AUTH chunks for received
ASCONF chunks would result in those chunks being dropped.  (I think
-- based on what the AUTH draft says.)  Receipt of the INIT/INIT-ACK
chunks that did not include ASCONF in the Supported Extensions is not
discussed, so I can not be sure whether the result of modifying the INIT
to remove mention of ASCONF would be a failure to use ASCONF or a
failure of the association.

Section 4.3 describes each new Error Cause.  Each Error Cause contains
the "ASCONF-Request Correlation ID."  The draft says that "The sender of
the ASCONF can use this same value in the ASCONF-ACK to find which
request the response is for."  And yet, each Error Cause in the
ASCONF-ACK repeats the complete request parameter.  If the complete
request parameter (correlation id + value) really needs to be repeated,
is there some check to ensure that the request parameter's value matches
the correlation id?

(Note here: the chunks are expressed as TLVs, carry parameters that are
themselves TLVs and the values sometimes have "parameters" and those are
sometimes expressed as TLVs.  So it requires very very careful reading
when the Error Cause is said to include "TLV-Copied-From-ASCONF."  The
example helps because it uses requests that appeared in previous
examples.)

In Section 5.1, the procedure says:

  A3)  If no SCTP packet with one or more ASCONF Chunk(s) is
      outstanding (un-acknowledged) with the remote peer, send the
      chunk.

  A4)  The sender MUST Start a T-4 RTO timer, using the RTO value of
      the selected destination address (normally the primary path; see
      RFC2960 [RFC2960] section 6.4 for details).


A4 is presumably only done if A3 resulted in the transmission of a
chunk.  If there is already an un-acknowledged SCTP packet carrying a
ASCONF chunk, presumably the new ASCONF chunk is queued for later
transmission.  The text here should be explicit, as this is the
procedure.

In step B4, it says "sequence number" when I think it means "serial
number."

Section 5.2 describes the procedure upon receipt of an ASCONF chunk.
Part of this procedure is associating the packet with the appropriate
association.  Part of that must also produce the association key for
checking the AUTH chunk.  But the verification of the AUTH chunk is not
mentioned in the procedure, although the verification of the
Verification Tag is mentioned.  It would be nice to say where the AUTH
verification occurs.

In D2-ext:

  D2-ext)  If more than one ASCONF Chunks are packed together, use the
      address found in the ASCONF Address Parameter TLV of the each of
      the subsequent ASCONF Chunks.

I think there are some extra words in the "of the each of the" part.

  E1)  If the value found in the serial number of the ASCONF Chunk is
      equal to the ('Peer-Serial-Number' + 1) and the Serial Number of
      the ASCONF Chunk is the first in the SCTP Packet,

  E1-ext  If the value found in the serial number of the ASCONF Chunk
      is equal to the ('Peer-Serial-Number' + 1) and the ASCONF chunk is
      NOT the first Serial Number in the SCTP packet


I am not sure what the serial number being the first in the packet or
the chunk is the first serial number in the packet.  I believe that this
means that the *chunk* is the first or not the first in the packet.  I
believe that "serial number" is a term used only in the ASCONF chunks,
but I have not reviewed all sctp documents.

Multiple ASCONF chunks are supposed to be placed in the packet in
increasing order of their serial numbers.  So the first ASCONF in the
received packet should have the least serial number.  But what if it
doesn't (the sender messes up)?  Is this text attempting to say that you
process the ASCONF chunks in the order they appear, whatever order their
serial numbers are in?  Or is it trying to say that you process the
ASCONF chunks in the order of their serial numbers, whatever order they
appear in the packet?

In Section 5.3.2:

  should attempt to use the address found in the Address Bytes field

"Address Bytes" I think is supposed to be "Address Parameter."

In Section 5.4:

  A sender of this option may elect to send this combined with a
  deletion or addition of an address.  A sender SHOULD only send a set
  primary request to an address that is already considered part of the
  association.  In other words if a sender combines a set primary with
  an add of a new IP address the set primary will be discarded unless
  the add request is to be processed BEFORE the set primary (i.e. it
  precedes the set primary).

Is the first "may elect" supposed to be "MAY elect", or is this a normal
"could possibly elect?"

The text says that a set primary "will be discarded", but that the
sender "SHOULD only send."  So is the "will be discarded" certain?  If
so, perhaps the text should say "MUST only send?"  If not, perhaps the
text should say "might be discarded?"

In the last paragraph of the section, change "should NOT" to "SHOULD
NOT."

Section 6:

  When using a wildcard address for adding or deleting an address the
  source address of the packet is used.

Or when setting the primary address.

In section 7, it makes many statements like "We recommend 0x80 but any
other available code point with the upper bit set is also acceptable."
If IANA should choose a different code point, will they edit the rest of
the draft where that value is mentioned?.  I ask because I don't know.

Section 8: replace "there" with "their" in both cases.

[Ballot comment]
Christian Vogt's review:

I was reading the protocol spec primarily with two questions in mind:
How does the protocol prevent session hijacking, and how does it protect
against 3rd-party flooding.

Session hijacking
-----------------

The Add-IP protocol is robust to session hijacking.  Hijacking is
prevented by exchanging random values and negotiating a hash algorithm
at session establishment based on which requests to add or remove an IP
address can be authenticated subsequently.  A session hijacker would
have to intercept these parameters during session establishment.  The
Add-IP protocol thereby successfully binds any IP address
additions/deletions to the initial connection setup.  Optionally, the
authentication mechanism can take advantage of shared secrets between
the peers so that sessions cannot be hijacked even if the attacker can
eavesdrop on connection establishment.

The authentication protocol is specified separately in
draft-ietf-tsvwg-sctp-auth-08.txt.

What is not mentioned in the Add-IP protocol spec, but which increases
the robustness of the protocol against connection hijacking IMO, is that
an attacker would also need to know a current sequence number.  I.e.,
the attacker would have to be on-path at connection setup AND shortly
before the attack.  (The additional robustness is small, of course,
given that a sequence number can be guessed.)

Flooding attacks
----------------

Flooding attacks are not properly protected against, however.  According
to the draft, the receiver of an Add-IP request is supposed to probe the
new IP address with a HEARTBEAT chunk, which in turn is to be echoed by
the requesting node.  Yet the HEARTBEAT chunk includes only predictable
information according to the SCTP base spec -- a timestamp and the
requesting node's IP address --, and the Add-IP spec does not overwrite
this.  Theoretically, it would be perfectly feasible to include
unpredictable information in a HEARTBEAT chunk, but this is nowhere
demanded AFAICT.

Flooding attacks are also not discussed in the security considerations.

The flooding issue in SCTP Add-IP is similar to the one Mobile IPv6
avoids with periodic care-of address tests.  But I think it's even more
significant because SCTP Add-IP allows an attacker to register multiple
IP addresses with a peer.  A flooding attacker could hence register its
own IP address in addition to the victim's IP address, and send faked
acknowledgments from a /topologically correct/ IP source address.  Since
Mobile IPv6 permits only a single care-of address per mobile node, it at
least forces a flooding attacker to spoof the victim's IP address in its
fake acknowledgments.

Similarly, SCTP Add-IP allows the attacker to use an IP source address
for the Add-IP request that is different than the IP address being
added.  The IP source address may therefore be topologically correct,
while the IP address being added could belong to a victim.  This is the
same issue that was discussed in the context of the Mobile IPv6
Alternative Care-of Address option.  But in contrast to Mobile IPv6,
SCTP Add-IP does not properly verify such an IP address, as explained above.

Suggestion:  (1) Add text that demands the use of unpredictable
information in HEARTBEAT chunks.  (2) Discuss the threat of flooding in
security associations.

Miscellaneous
-------------

I very much think that the document could be improved editorially.  I
found it difficult to read.  The following piece of text from page 25 is
quite representative, I would say:

> >              The receiver of the add IP address request may use the
> >      address as a destination immediately.  The receiver MUST use the
> >      path verification procedure for the added address before using
> >      that address.  The receiver MUST NOT send packets to the new
> >      address except for the corresponding ASCONF-ACK Chunk or HEARTBEAT
> >      Chunks for path verification before the new path is verified.

Another example is that the reader finds out only very late and in a
hidden place (in a side note in section 4.2.6) that the "adaptation
indication" specified in the document has nothing to do with mobility or
multi-homing, but was merely included to spare another SCTP document.

There are more examples of highly improvable text, but I'll leave it for
now...

[Ballot discuss]
This document looks good, but I am concerned about one thing.
Specifically, if used together with the original SCTP RFC,
there is no requirement that heartbeats employ random data.
This could lead to a bombing vulnerability documented in
draft-ietf-tsvwg-sctpthreat, see also the review from
Christian Vogt in the comments.

Obviously, this has been fixed in RFC 4460, but it is
informational. Interestingly, addip does not reference
rfc2960bis although that is is already in IESG processing.
I would suggest referencing it normatively and explicitly
mentioning the need to use random nonces from Section 5.4.

[Ballot discuss]
This document looks good, but I am concerned about one thing.
Specifically, if used together with the original SCTP RFC,
there is no requirement that heartbeats employ random data.
This could lead to a bombing vulnerability document in
draft-ietf-tsvwg-sctpthreat, see also the review from
Christian Vogt in the comments.

Obviously, this has been fixed in RFC 4460, but it is
informational. Interestingly, addip does not reference
rfc2960bis although that is is already in IESG processing.
I would suggest referencing it normatively and explicitly
mentioning the need to use random nonces from Section 5.4.

[Ballot comment]
The Technical Summary in the Write-up is better than the Abstract
  in the document.  I suggest that it be used as the Abstract:
 
    A local host may have multiple points of attachment to the
    Internet, giving it a degree of fault tolerance from
    hardware failures. SCTP was developed to take full advantage
    of such a multi-homed host to provide a fast failover and
    association survivability in the face of such hardware
    failures. This document describes an extension to SCTP that
    will allow an SCTP stack to dynamically add an IP Addresses
    to an SCTP association, dynamically delete an IP addresses
    from an SCTP association, and to request to set the primary
    address the peer will use when sending to an endpoint.

  Based on Gen-ART Review by Francis Dupont:

  Section 3: s/2*32/2**32/ OR s/2*32/2^32/

  Section 4.1.1: s/message i.e./message, i.e.,/

  Section 4.2: s/Table 2, 3 and 4/Tables 2, 3, and 4/

  Section 4.2.4: s/appear in the ASCONF Chunk,/appear in the ASCONF,/

  Section 4.3: s/illegal ASCONF-ACK/illegal ASCONF-ACK./

  Section 4.3.4: s/2^^31/2**31/ OR s/2^^31/2^31/

  Section 5.1.1: s/a minimal path MTU.  The minimum PMTU/
                  /a minimal path MTU.  The minimal path MTU/

  Section 5.2: s/i.e./i.e.,/ (two places)

  Section 5.2: insert a blank line before E1, E2, and V3

  Section 5.2: s/PMTU/path MTU/

  Section 5.3: s/2^^31/2**31/ OR s/2^^31/2^31/

  Section 5.3.1: s/rule D4/rule F4/ (on page 28)

  Section 5.4: s/i.e./i.e.,/

  Section 5.5: s/other i.e./other, i.e.,/

  Section 5.5: s/Each new ASCONFs lookup/Each new ASCONF lookup/

  Section 6: s/modfiy/modify/

IANA Last Call Comments:

[ Note: The IANA Considerations section is incomplete.
The following actions were obtained from the document
itself. ]

Upon approval of this document, the IANA will take the
following Actions:

Action 1:

Upon approval of this document, the IANA will make the
following assignments in the "SCTP Parameters" registry
located at

http://www.iana.org/assignments/sctp-parameters

sub-registry "CHUNK TYPES"

ID Value Chunk Type Reference
----- ---------- ---------
[TBD-193] Address Configuration Change Chunk (ASCONF)
[RFC-tsvwg-addip-sctp-20]
[TBD-128] Address Configuration Acknowledgment (ASCONF-ACK)
[RFC-tsvwg-addip-sctp-20]

Note that the values TBD values will get assigned from
the appropriate ranges in the registry, but that "193"
and "128" may not specifically get assigned. Section 4.1
should get updated as well with the assigned value.


Action 2:

Note: The IANA Considerations is incomplete on this
action. Section 4.2, however, has more information on
the assignment.

Upon approval of this document, the IANA will make
the following assignments in the "SCTP Parameters"
registry located at

http://www.iana.org/assignments/sctp-parameters

sub-registry "CHUNK PARAMETER TYPES"

--INIT Chunk Parameter Types

Chunk Parameter Type Value
-------------------- -----
Set Primary Address TBD (suggested 0xC004)
Adaptation Layer Indication TBD (suggested 0xC006)
Supported Extensions TBD (suggested 0x8008)


--INIT ACK Chunk Parameter Types

Chunk Parameter Type Value
-------------------- -----
Set Primary Address TBD (suggested 0xC004)
Adaptation Layer Indication TBD (suggested 0xC006)
Supported Extensions TBD (suggested 0x8008)

-- ASCONF Chunk Parameter Types [RFC-tsvwg-addip-sctp-20]

Chunk Parameter Type Value
-------------------- -----
Add IP Address TBD (suggested 0xC001)
Delete IP Address TBD (suggested 0xC002)
Set Primary Address TBD (suggested 0xC004)

-- ASCONF ACK Chunk Parameter Types [RFC-tsvwg-addip-sctp-20]

Chunk Parameter Type Value
-------------------- -----
Error Cause Indication TBD (suggested 0xC003)
Success Indication TBD (suggested 0xC005)


Action 3:

Upon approval of this document, the IANA will make
the following assignments in the "SCTP Parameters"
registry located at

http://www.iana.org/assignments/sctp-parameters

sub-registry "CAUSE CODES"

VALUE CAUSE CODE REFERENCE
----- ---------------- ---------
[TBD] Request to Delete Last Remaining IP Address.
[RFC-tsvwg-addip-sctp-20]
[TBD] Operation Refused Due to Resource Shortage.
[RFC-tsvwg-addip-sctp-20]
[TBD] Request to Delete Source IP Address.
[RFC-tsvwg-addip-sctp-20]
[TBD] Association Aborted due to illegal ASCONF-ACK
[RFC-tsvwg-addip-sctp-20]
[TBD] Request refused - no authorization.
[RFC-tsvwg-addip-sctp-20]


Action 4:

Upon approval of this document, the IANA will in
the following registry "SCTP Parameters" located at

http://www.iana.org/assignments/sctp-parameters

create a new sub-registry "Adaptation Code Points"

Registration Policy: "IETF Consensus"
Initial contents of this sub-registry will be:

Code Point Description Reference
(32-bit number)
---------- ----------- ---------
0-0xffffffff Reserved to IANA [RFC-tsvwg-addip-sctp-20]


We understand the above to be the only IANA Actions
for this document.

State Change Notice email list have been change to tsvwg-chairs@tools.ietf.org, rrs@cisco.com, tuexen@fh-muenster.de, qxie1@email.mot.com, mail@marushin.gr.jp, ma-kun@kozuka.jp from tsvwg-chairs@tools.ietf.org, rrs@cisco.com, tuexen@fh-muenster.de, peterlei@cisco.com, ekr@rtfm.com, mramalho@cisco.com, qxie1@email.mot.com

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

James Polk is the Document Shepherd. I have reviewed this version of
the document, and believe this is ready to forward to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, key members of the WG have reviewed this document. no concerns

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No. Although not all within TSVWG want to know about SCTP, I feel
confident that the appropriate people reviewed and commented on this document.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No additional concerns. There is no IPR on the contents of this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There WG consensus amongst those in the WG that are interested in
SCTP, with others being silent. This doc been reviewed by many people.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No threats that I am aware of.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes, I have, and there are no errors, 1(incorrect) warning, and no comments.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are not split. This document is standards track, and
all references are normative, with DOWNREF no issues.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists and is consistent with the
body of the document. The appropriate reservations within the IANA
registries have been requested. The IANA registries are clearly
identified. There are 13 a new registry items being requested (2 SCTP
Chunk types, 6 SCTP parameter types, and 5 new SCTP error types. All
of these are reasonable.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

I verified the XML sections are valid.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

* Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

A local host may have multiple points of attachment to the Internet,
giving it a degree of fault tolerance from hardware failures. SCTP
was developed to take full advantage of such a multi-homed host to
provide a fast failover and association survivability in the face of
such hardware failures. However, many modern computers allow for the
dynamic addition and deletion of network cards (sometimes termed a
hot-pluggable interface). Complicate this with the ability of a
provider, in IPv6, to dynamically renumber a network, and there still
is a gap between full fault tolerance and the currently defined SCTP
protocol. No matter if a card is added or an interface is
renumbered, in order to take advantage of this new configuration, the
transport association must be restarted. For many fault tolerant
applications this restart is considered an outage and is undesirable.

This document describes an extension to SCTP to attempt to correct
this problem for the more demanding fault tolerant application. This
extension will allow an SCTP stack to: Dynamically add an IP
Addresses to an association, Dynamically delete an IP Addresses from
an association, Request to set the primary address the peer will use
when sending to an endpoint.

* Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

There is WG consensus to publish this document. It has been reviewed
by several people in the WG last call. Comments raised has been addressed.

* Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

I know of no implementations of this extension to date.

* Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

James Polk is the document Shepherd. Lars Eggert or Magnus Westerlund
is the responsible Area Director.