80 likes | 205 Views
SCTP as a transport for Diameter draft-pascual-dime-sctp-00 . victor.pascual@acmepacket.com gonzalo.camarillo@ericsson.com IETF 79 - DIME WG November 2010, Beijing, China. Motivation. Clarify/specify the usage of Diameter over SCTP and its associated security mechanisms .
E N D
SCTP as a transport for Diameter draft-pascual-dime-sctp-00 victor.pascual@acmepacket.com gonzalo.camarillo@ericsson.com IETF 79 - DIME WGNovember 2010, Beijing, China
Motivation • Clarify/specify the usage of Diameter over SCTP and its associated security mechanisms
draft-ietf-dime-rfc3588bis-25 • The base protocol is defined to run over TCP, SCTP or TLS • assuming that TLS is run on top of TCP when it is used • The use of a secured transport for exchanging Diameter messages is mandatory • being TLS the primary method and IPsec a secondary alternative • A TLS-like mechanism for Diameter over SCTP is desired
TLS over SCTP has some serious limitations • These are documented in draft-ietf-tsvwg-dtls-for-sctp-06 • Examples: • It does not support the unordered delivery of SCTP user messages • It uses a TLS connection for every bidirectional stream, which requires a substantial amount of resources and message exchanges if a large number of streams is used • TLS over SCTP has seen very little deployment, if any
DTLS over SCTP overcomes the limitations of TLS over SCTP • DTLS over SCTP supports all features SCTP support. Examples: • It does support the unordered delivery of SCTP user messages • It uses one DTLS connection per SCTP association • The IESG has recently approved it as a Proposed Standard and it will be published as a Standards Track RFC • Proposal: adopt DTLS over SCTP as a security mechanism for Diameter
Mapping of Diameter messages into SCTP streams • Diameter messages need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking • Mapping diameter messages into different SCTP streams could fulfill this requirement but some increase of processing delay might be incurred • Sending every Diameter message via the SCTP Stream ID zero with the “unordered” flag set leads to improved performance and simplicity • Proposal: “a Diameter entity SHOULD send every Diameter message over stream zero with the unordered flag set. On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream”
Questions to the WG • Is this something we should work on? • Where? • rfc3588bis vs separate document