Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-05

[Ballot discuss]
[Note: I understand that the editors were constrained by the contents of RFC 4460, so this may
be out of scope.  However...]

Section 10.2.2 (Security Considerations/Protecting Against Data Corruption In The Network)
specifies that the Authentication Header SHOULD be used when stronger integrity protection
is required.  AH is certainly one solution, but ESP-NULL with IKEv2 provides an alternative
solution.  Given that the current IPsec architecture requires support for ESP and makes AH
optional, has the WG considered use of ESP-NULL?

In addition, Sandy Murphy's secdir review of tsvwg-addip includes the following comments on
2960bis.  Please ensure they are considered as Last Call comments on this document:


I did not review this document completely, but I did note a few things
relevant to the security of the new addip feature of
draft-ietf-tsvwg-addip-sctp-20.txt.  The threats draft notes that the
HEARTBEAT feature prevents an attacker from "bombing" a victim address
by adding its address to the association and then ensuring that that
address becomes primary in the midst of a large data transfer.  The
HEARTBEAT feature is supposed to verify the path by doing a
challenge/response.  However, if the challenge of the HEARTBEAT is
predictable, then the attacker can spoof the response in a HEARTBEAT
ACK.  The HEARTBEAT is said to be a 64-bit random nonce in some places,
but in the description of the HEARTBEAT packet in Section 3.3.5 it says:

      The Sender-specific Heartbeat Info field should normally include
      information about the sender's current time when this HEARTBEAT
      chunk is sent and the destination transport address to which this
      HEARTBEAT is sent (see Section 8.3).


A sender's current time might not be unpredictable enough to prevent the
attacker from constructing a spoofed HEARTBEAT-ACK.

The Security Considerations section is nicely done.  It mentions using
AH and ESP to protect authenticity and confidentiality, although it
doesn't distinguish tunnel mode from transport mode.  It says to use
IKEv2 is using ESP, but as I mentioned earlier, using these protocols
between a number of different, changing endpoints is at least difficult.
How they could be used should be mentioned.

[Ballot comment]
Section 11.3 on fraud seems to have no place in this document.  I
don't think it adds to the document and found it long-winded.  As an
individual I recommend removing it.

[Ballot discuss]
Section 11.2.2 recommends that AH be used for replay protection and integrity protection.
I thought there was an SCTP-specific authentication option.
Isn't that a better fit?

If you are going to recommend IPsec please recommend ESP with no
confidentiality rather than AH.  PER RFC 4301 AH is no longer mandatory
to implement.


The security considerations need to discuss how SCTP interacts with
the SPD when IPsec is used to protect it.  In particular, it seems
like you can get some really unfortunate situations when some of the
addresses in a security association are covered by different SPD rules
than others.  If you are going to recommend use of IPsec this is
particularly concerning, and if you are going to recommend IPsec be
used, I think you need to give implementation advice on how an SCTP or
IPsec implementation can avoid these problems.

Noting that there is a BSD sockets API to request AH is problematic.
First, that API doesn't really work with RFC 2401 or 4301; it's not
clear how such a request interacts with the SPD.  You might choose to
ignore this nice people don't really implement 2401 or 4301 and do
implement such an API and I can see how you might argue that running
code trumps long documents.  However it's also misleading in that in
order for such an option to be useful you have to somehow have the
security negotiation work.  I.E. shared keys, IKE configuration, etc.

[Ballot discuss]
[Note: I understand that the editors were constrained by the contents of RFC 4460, so this may
be out of scope.  However...]

Section 10.2.2 (Security Considerations/Protecting Against Data Corruption In The Network)
specifies that the Authentication Header SHOULD be used when stronger integrity protection
is required.  AH is certainly one solution, but ESP-NULL with IKEv2 provides an alternative
solution.  Given that the current IPsec architecture requires support for ESP and makes AH
optional, has the WG considered use of ESP-NULL?

[Ballot discuss]
[Note: I understand that the editors were constrained by the contents of RFC 4460, so this may be out of scope.  However...]

Section 10.2.2 (Security Considerations/Protecting Against Data Corruption In The Network) specifies that the Authentication Header SHOULD be used when stronger integrity protection is required.  AH is certainly one solution, but ESP-NULL with IKEv2 provides an alternative solution. 
Given that the current IPsec architecture requires support for ESP and makes AH optional, has the WG considered use of ESP-NULL?

[Ballot discuss]
[Note: I understand that the editors were constrained by the contents of RFC 4460, so this may be out of scope.  However...]

Section 10.2.2 (Security Considerations/Protecting Against Data Corruption In The Network) specifies that the Authentication Header SHOULD be used when stronger integrity protection is required.  AH is certainly one solution, but ESP-NULL with IKEv2 provides an alternative solution. 
Given that the current IPsec architecture requires support for ESP and makes AH optional, has the WG considered use of ESP-NULL?

[Ballot comment]
The suggested SCTP protocol parameter values defined in Section 15.
  Please add a forward pointer to Section 15 on the first occurrence
  of the use of a protocol parameter defined there.  It will help
  the reader find the default values for these parameters.

  Based on Gen-ART Review by Vijay K. Gurbani:

  In Section 1.3.1 consider replacing "against security attacks" with
  "against synchronization attacks".  The term "security" is too broad,
  and I believe that you are trying to prevent the likelihood of TCP SYN
  attacks in SCTP.

  Please consider putting Section 1.5 somewhere in the beginning.  Since
  the sub-sections that preceeded Section 1.5 use the abbreciations
  quite a bit, introducing the reader to the abbreviations early should
  help readability.
 
  In section 3.3.5, second paragraph, the text says that the parameter
  field contains an opaque data structure understood only by the sender.
  I think it will add more clarity to insert the following text at the
  end of the last paragraph in the section:

  OLD:
  The Sender-specific Heartbeat Info field should normally include
  information about the sender's current time when this HEARTBEAT
  chunk is sent and the destination transport address to which this
  HEARTBEAT is sent (see Section 8.3).

  NEW:
  The Sender-specific Heartbeat Info field should normally include
  information about the sender's current time when this HEARTBEAT
  chunk is sent and the destination transport address to which this
  HEARTBEAT is sent (see Section 8.3).  This information is simply
  reflected back by the receiver in the HEARTBEAT ACK message (see
  Section 3.3.6).

  In Section 11.2.2, it is stated that "A widely implemented BSD
  Sockets API extension exists for applications to request IP security
  services...".  Please provide a reference or drop the clause.

  Nit: S3, page 16: s/Section 6.10for/Section 6.10 for/

  Nit: S3.3.2.1, under the IPv6 address parameter figure:
  s/128 bit/128 bits/

  Nit: S4: s/description of all special cases should be found in the text/
  /description of all special cases are found in the text/

  Nit: S7.1, first bullet: s/layer otherwise/layer to do otherwise/

[Ballot comment]
1. The header of the document on the front page should mention that this document obsoletes RFC 2960 and RFC 4460 when approved.

2. The Network Management Considerations section says:

  A MIB for SCTP is defined in [RFC3873].

As this document succeeds in time RFC3873 it would be useful replace this statment with:

The MIB module for SCTP defined in [RFC3873] applies for the version of the protocol specified in this document.

IANA Last Call Comments:

*** IANA has Questions.

Upon Approval of this document the IANA will take the
following Actions.

Action 1: Section 14 says:

This protocol will require port reservation like TCP for
the use of "well known" servers within the Internet. All
current TCP ports shall be automatically reserved in the
SCTP port address space. New requests should follow
IANA's current mechanisms for TCP.

This appears to be a request to modify the "PORT
NUMBERS" Registry

at http://www.iana.org/assignments/port-numbers

*** Does this mean you want to block off all SCTP
port numbers as reserved? Does it mean you want to
block off all the existing TCP-assigned port numbers
as reserved for SCTP?
Or do you want to copy every TCP port assignment
and make an SCTP port assignment for each port?
*****

Action 2: Section 14.1 (refers back to section 3.2)

Upon approval of this document, the IANA will make the
following changes in "Stream Control Transmission
Protocol (SCTP) Parameters" registry located at

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

sub-registry "CHUNK TYPES"

****
[ Note: the contents of section 3.2 do not contain the
additional assignments already made by IANA. However
there are no conflicts so the RFC2960 references are
upgraded to RFC-tsvwg-2960bis-04 ]
****

OLD:
ID Value Chunk Type Reference
----- ---------- ---------
0 - Payload Data (DATA) [RFC2960]
1 - Initiation (INIT) [RFC2960]
2 - Initiation Acknowledgement (INIT ACK) [RFC2960]
3 - Selective Acknowledgement (SACK) [RFC2960]
4 - Heartbeat Request (HEARTBEAT) [RFC2960]
5 - Heartbeat Acknowledgement (HEARTBEAT ACK) [RFC2960]
6 - Abort (ABORT) [RFC2960]
7 - Shutdown (SHUTDOWN) [RFC2960]
8 - Shutdown Acknowledgement (SHUTDOWN ACK) [RFC2960]
9 - Operation Error (ERROR) [RFC2960]
10 - State Cookie (COOKIE ECHO) [RFC2960]
11 - Cookie Acknowledgement (COOKIE ACK) [RFC2960]
12 - Reserved for Explicit Congestion Notification [RFC2960]
Echo (ECNE)
13 - Reserved for Congestion Window Reduced (CWR) [RFC2960]
14 - Shutdown Complete (SHUTDOWN COMPLETE) [RFC2960]
15 - Authentication Chunk (AUTH) [RFC-ietf-tsvwg-sctp-auth-08.txt]
16 to 62 - reserved by IETF
63 - IETF-defined Chunk Extensions
64 to 126 - reserved by IETF
127 - IETF-defined Chunk Extensions
128 to 131 - reserved by IETF
132 - Padding Chunk (PAD) [RFC4820]
133 to 190 - reserved by IETF
191 - IETF-defined Chunk Extensions
192 - Forward TSN [RFC3758]
193 to 254 - reserved by IETF
255 - IETF-defined Chunk Extensions

NEW:
ID Value Chunk Type Reference
----- ---------- ---------
0 - Payload Data (DATA) [RFC-tsvwg-2960bis-04]
1 - Initiation (INIT) [RFC-tsvwg-2960bis-04]
2 - Initiation Acknowledgement (INIT ACK) [RFC-tsvwg-2960bis-04]
3 - Selective Acknowledgement (SACK)
[RFC-tsvwg-2960bis-04]
4 - Heartbeat Request (HEARTBEAT) [RFC-tsvwg-2960bis-04]
5 - Heartbeat Acknowledgement (HEARTBEAT ACK) [RFC-tsvwg-2960bis-04]
6 - Abort (ABORT) [RFC-tsvwg-2960bis-04]
7 - Shutdown (SHUTDOWN) [RFC-tsvwg-2960bis-04]
8 - Shutdown Acknowledgement (SHUTDOWN ACK) [RFC-tsvwg-2960bis-04]
9 - Operation Error (ERROR) [RFC-tsvwg-2960bis-04]
10 - State Cookie (COOKIE ECHO) [RFC-tsvwg-2960bis-04]
11 - Cookie Acknowledgement (COOKIE ACK) [RFC-tsvwg-2960bis-04]
12 - Reserved for Explicit Congestion Notification [RFC-tsvwg-2960bis-04]
Echo (ECNE)
13 - Reserved for Congestion Window Reduced (CWR) [RFC-tsvwg-2960bis-04]
14 - Shutdown Complete (SHUTDOWN COMPLETE) [RFC-tsvwg-2960bis-04]
15 - Authentication Chunk (AUTH) [RFC-ietf-tsvwg-sctp-auth-08.txt]
16 to 62 - reserved by IETF
63 - IETF-defined Chunk Extensions
64 to 126 - reserved by IETF
127 - IETF-defined Chunk Extensions
128 to 131 - reserved by IETF
132 - Padding Chunk (PAD) [RFC4820]
133 to 190 - reserved by IETF
191 - IETF-defined Chunk Extensions
192 - Forward TSN [RFC3758]
193 to 254 - reserved by IETF
255 - IETF-defined Chunk Extensions


Action 3: Section 14.2 (refers back to section 3.2.1)
Section 3.2.1 then refers back to section 14.2 for contents.

****
There appear to be no assignments in this section.
Is this correct?
****

Action 4: Section 14.3 (refers back to section 3.3.10)

The Cause Code table in section 3.3.10 conflicts with the current
registry "Stream Control Transmission Protocol (SCTP) Parameters"
located at http://www.iana.org/assignments/sctp-parameters
sub-registry "CAUSE CODES"

****
In particular, section 3.3.10 tries to assign cause-code 11 to
"Restart of an Association with New Addresses" whereas the IANA
registry already assigned this cause code to "Unsupported HMAC
Identifier".

How do the authors want IANA to handle this conflict?
****

Action 4: Section 14.4

Upon approval of this document, the IANA will make the
following assignments in the "Stream Control Transmission
Protocol (SCTP) Parameters" registry located at

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


sub-registry "SCTP Payload Protocol Identifiers"

SCTP Payload Protocol Identifiers REFERENCE
--------------------------------- ---------
0 - Reserved by SCTP [RFC-tsvwg-2960bis-04]

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 of the WG have reviewed this document.
There are 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 concerns.

(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, there are no additional concerns. There is no IPR wrt 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 solid WG consensus behind this document - of those within TSVWG
that are interested in SCTP, with others being silent.

(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 appeals have been threatened on this document's publication.

(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. There are no errors, 6 warnings (all wrong) and 5
comments (all wrong) reported in this document.

(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 split. There are no downward references in this
version of the document.

(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 several new registries being requested

-- through definition of additional chunk types,
-- through definition of additional parameter types, or
-- through definition of additional cause codes within ERROR chunks

All are appropriately written.

(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?

There is no formal language in this document, such as XML code, BNF
rules, MIB definitions, etc.

(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.

This document obsoletes RFC2960 [RFC2960] and describes the Stream
Control Transmission Protocol (SCTP). SCTP is designed to transport
PSTN signaling messages over IP networks, but is capable of broader
applications.

SCTP is a reliable transport protocol operating on top of a
connectionless packet network such as IP. It offers the following
services to its users:

-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi- homing
at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.

* 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 strong consensus in the WG to publish this document among
those within TSVWG that are interested in SCTP. 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?

There are existing implementations of this protocol revision. Several
vendors appear to be ready to implement this protocol, if they have
not done so already.

* 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.