Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
RFC 4895
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Lars Eggert No Objection
(Magnus Westerlund; former steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) (was Discuss) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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?
(Jon Peterson; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (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.
(Ted Hardie; former steering group member) No Objection
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.