Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
draft-ietf-tsvwg-sctpthreat-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the Yes position for Sam Hartman |
2007-07-16
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-06-17
|
05 | (System) | IANA Action state changed to No IC from In Progress |
2007-06-17
|
05 | (System) | IANA Action state changed to In Progress |
2007-06-15
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-06-15
|
05 | Amy Vezza | IESG has approved the document |
2007-06-15
|
05 | Amy Vezza | Closed "Approve" ballot |
2007-06-15
|
05 | Lars Eggert | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert |
2007-06-14
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-06-14
|
05 | (System) | New version available: draft-ietf-tsvwg-sctpthreat-05.txt |
2007-06-13
|
05 | Lars Eggert | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Lars Eggert |
2007-06-13
|
05 | Lars Eggert | There is a final revision coming with some editorial fixes. (Note to self: add RFC Editor Note with some additional ones.) |
2007-06-12
|
05 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman |
2007-06-12
|
05 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk |
2007-06-12
|
05 | Lars Eggert | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Lars Eggert |
2007-06-12
|
05 | Lars Eggert | Asked reviewers and ADs to check off on the new revision. |
2007-06-11
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-06-11
|
04 | (System) | New version available: draft-ietf-tsvwg-sctpthreat-04.txt |
2007-05-25
|
05 | (System) | Removed from agenda for telechat - 2007-05-24 |
2007-05-24
|
05 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2007-05-24
|
05 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-05-24
|
05 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
2007-05-23
|
05 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-05-23
|
05 | Russ Housley | [Ballot comment] Section 2.2: s/In closely examination this/In close examination, this/ Section 3: s/end to end/end-to-end/ Section 3.3: s/set of two 32 … [Ballot comment] Section 2.2: s/In closely examination this/In close examination, this/ Section 3: s/end to end/end-to-end/ Section 3.3: s/set of two 32 bit nonces/pair of 32-bit nonces/ Section 4.1: s/full four way handshake/full four-way handshake/ Section 6.3: s/end point should/end point should:/ Section 7.1: s/header i.e. X+1 or Y+1/header, i.e., X+1 or Y+1/ s/set's up/sets up/ From the Gen-ART Review by Miguel Garcia: The document is well written. And, I agree. |
2007-05-23
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-05-23
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-05-23
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-05-22
|
05 | Tim Polk | [Ballot discuss] I have not seen any response to Magnus Nystrom's SecDir review. While none of the comments is a deal breaker, I believe these … [Ballot discuss] I have not seen any response to Magnus Nystrom's SecDir review. While none of the comments is a deal breaker, I believe these changes would improve the document. I have included his comments as the body of this discuss to ensure the authors have reviewed these issues. General: -------- - This seems to be a very useful document rooted in implementation experiences. I get a sense it would be good to have similar documents for a range of other protocols. - The wording in the abstract seems a bit convoluted or unclear to me, e.g., "... This document attempts to detail the known security threats and their countermeasures as detailed in the current version of the SCTP Implementors guide RFC 4460." I'd prefer something more succinct, such as just: "This document describes certain security threats to the Stream Control Transmission Protocol (SCTP, RFC 2960). It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460)." - The language needs to be cleaned up. Just a few examples: "there" -> "their", "a endpoint" -> "an endpoint", "mis-setup". - [3] is referred to as "Implementors Guide" but really that is not the title, right? (BTW, it is a bit confusing that [3] is titled "Errata and Issues" and published as an Informational RFC when it really seems to be updating the base protocol specification. That is outside the scope of this review, however). - Several typically normative statements such as "An SCTP implementation should abort the association if..." uses lower-case keywords - is this intentional? Would not you want these statements to be normative? Detailed: --------- - Section 2.1: a) "...port number client uses..." - will use or is already using? Perhaps clarify? b) Maybe say something about how the server will realize that the attacker does not legitimately hold IP-C? E.g. by having a forward reference to Section 2.2? - Section 2.2: a) Item 3, last sentence not clear: "...then the client's INIT message would restart the attackers association destroying it."? b) What if the attacker re-initialize as soon as he has been dis-associated? - Section 4.3: a) Any value in detailing a little bit the restart notifications provided by SCTP (e.g. by referring to them in 2960?)? - Section 6.3: a) Suggest to clarify where the Max.Burst recommendation value is given (is it in RFC 4460?). - Section 7.3: a) If the implementation just discards the invalid COOKIE, doesn't that still mean that resources has been tied up at the contacted party? -- Magnus |
2007-05-22
|
05 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2007-05-22
|
05 | Sam Hartman | [Ballot discuss] This is a very well written document and I found it quite useful. However there is one area where I think a fix … [Ballot discuss] This is a very well written document and I found it quite useful. However there is one area where I think a fix is needed. The document talks at several points about an attack only being possible if an attacker owns a given IP address. I don't know what is meant by owning a given IP address, but I suspect in many cases whatever is meant is not required. As an example, an attacker that can see traffic to a given IP, suppress traffic from that IP and source traffic from that IP seems to be able to mount these attacks. Inaddition, suppressing traffic may not be required. I'd recommend a more clear explanation of what is required to mount the attack in these cases. |
2007-05-22
|
05 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-05-22
|
05 | Lars Eggert | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert |
2007-05-21
|
05 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-05-21
|
05 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-05-21
|
05 | Dan Romascanu | [Ballot comment] The document does not split the references andincludes only an Informative References section. The PROTO write-up explains this on the grounds that the … [Ballot comment] The document does not split the references andincludes only an Informative References section. The PROTO write-up explains this on the grounds that the document is Informationat. I believe that this is wrong, as an Informational document may yet contain Normative References if these are essential reading for the understanding or implementation of the document. This seems to me to be the case with the SCTP protocol documents here. |
2007-05-17
|
05 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom. |
2007-05-17
|
05 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-05-17
|
05 | Yoshiko Fong | IANA Last Call Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2007-05-11
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2007-05-11
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2007-05-07
|
05 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert |
2007-05-07
|
05 | Lars Eggert | Ballot has been issued by Lars Eggert |
2007-05-07
|
05 | Lars Eggert | Created "Approve" ballot |
2007-05-07
|
05 | Amy Vezza | Last call sent |
2007-05-07
|
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-05-07
|
05 | Lars Eggert | Placed on agenda for telechat - 2007-05-24 by Lars Eggert |
2007-05-07
|
05 | Lars Eggert | [Note]: 'Document Shepherd: James Polk (jmpolk@cisco.com)' added by Lars Eggert |
2007-05-07
|
05 | Lars Eggert | Tentatively on the agenda for May 24, 2007. |
2007-05-07
|
05 | Lars Eggert | Last Call was requested by Lars Eggert |
2007-05-07
|
05 | Lars Eggert | State Changes to Last Call Requested from AD Evaluation by Lars Eggert |
2007-05-07
|
05 | (System) | Ballot writeup text was added |
2007-05-07
|
05 | (System) | Last call text was added |
2007-05-07
|
05 | (System) | Ballot approval text was added |
2007-05-04
|
05 | Lars Eggert | State Changes to AD Evaluation from Publication Requested by Lars Eggert |
2007-05-04
|
05 | Lars Eggert | State Change Notice email list have been change to tsvwg-chairs@tools.ietf.org, rrs@cisco.com, tuexen@fh-muenster.de, gonzalo.camarillo@ericsson.com from tsvwg-chairs@tools.ietf.org |
2007-05-04
|
05 | Dinara Suleymanova | 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, … 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. 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? I have no concerns about 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. I have no concerns about this document. There is IPR for 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 the SCTP community of TSVWG, with others being silent. The WG as a whole does not focus on SCTP, but those that do, are in consensus wrt this document's progression. (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, there are no threats on this document. (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, there are no errors, one warning due to a recent update of a reference, 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 because this document is only Informational, therefore all references are informational. (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 is empty, and can be left empty or removed in the RFC-Editor process. (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 have verified this (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. Stream Control Transmission Protocol defined in RFC 2960 is a multi- homed transport protocol. As such, unique security threats exists that are addressed in various ways within the protocol itself. This document attempts to detail the known security threats and their countermeasures as detailed in the current version of the SCTP Implementers guide RFC 4460. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Implementers guide * 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? Example: There is strong consensus in the WG 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? This is not a protocol document, therefore there are no implementations of what this document offers. * 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. |
2007-05-04
|
05 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2007-05-04
|
05 | Dinara Suleymanova | Intended Status has been changed to Informational from None |
2007-04-05
|
03 | (System) | New version available: draft-ietf-tsvwg-sctpthreat-03.txt |
2006-10-19
|
02 | (System) | New version available: draft-ietf-tsvwg-sctpthreat-02.txt |
2006-08-08
|
05 | (System) | State Changes to AD is watching from Dead by system |
2006-08-07
|
01 | (System) | New version available: draft-ietf-tsvwg-sctpthreat-01.txt |
2006-08-05
|
05 | (System) | State Changes to Dead from AD is watching by system |
2006-08-05
|
05 | (System) | Document has expired |
2006-06-12
|
05 | Lars Eggert | Draft Added by Lars Eggert in state AD is watching |
2006-01-20
|
00 | (System) | New version available: draft-ietf-tsvwg-sctpthreat-00.txt |