IETF 79 - Diameter Over SCTP

2,704 views
2,551 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,704
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

IETF 79 - Diameter Over SCTP

  1. 1. SCTP as a transport for Diameter draft-pascual-dime-sctp-00 vpascual@acmepacket.com gonzalo.camarillo@ericsson.com IETF 79 - DIME WG November 2010, Beijing, China
  2. 2. Motivation • Clarify/specify the usage of Diameter over SCTP and its associated security mechanisms
  3. 3. 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
  4. 4. 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
  5. 5. DTLS over SCTP overcomes the limitations of TLS over SCTP • DTLS over SCTP supports all features SCTP supports. 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
  6. 6. 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”
  7. 7. Questions to the WG • Is this something we should work on? • Where? – rfc3588bis vs. separate document

×