Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
Note: This ballot was opened for revision 08 and is now closed.
(Magnus Westerlund) Yes
(Jari Arkko) No Objection
Comment (2007-02-22 for -)
Does this document expect a separate shared secret to be configured between all pairs of communicating parties? This may be a big assumption. How does one "using TLS" create such a key? That may be a good approach, but I'm sure details are needed. Is there an IETF policy for defining key management and not just reliance on shared secrets for new protocols?
(Ross Callon) No Objection
(Brian Carpenter) (was Discuss) No Objection
(Lars Eggert) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2007-02-21 for -)
During a private exchange with the authors, it was clarified that this document works with the partial reliability extensions to SCTP. This will be made clear in an upcoming document (add-ip), but I believe it would be useful to add a short informational statement to this document to that effect.
(Russ Housley) (was Discuss) No Objection
Section 1 says: > > ... SCTP sender to sign chunks ... > I really dislike this use of "sign." I greatly prefer "authenticate." Since the specification demands that the random value must be exactly 32 octets in length, it would help the reader to say so in Section 3.1.