Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
RFC 4895

Note: This ballot was opened for revision 07 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

Comment (2007-02-19)
  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.

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection