Subject: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 21 Oct 2010 17:27:50 +0200

Hello,

If you don't mind I have some comments on draft-ietf-dime-rfc3588bis
and SCTP transport. Making the long story short, I believe RFC3588bis
shall discuss the implications of using Diameter over SCTP transport
and its associated security mechanisms.

There are some aspects I'd like to discuss:

-SCTP USAGE-

1) SCTP Payload Protocol Identifier for Diameter: IMO no SCTP
identifier needs to be defined for Diameter messages. Therefore, the
PPI in SCTP DATA chunks transporting Diameter messages MUST be set to
zero. I think this should be documented

2) Mapping of Diameter messages into SCTP Streams: the current version
of the draft states that "All Diameter nodes SHOULD utilize all SCTP
streams available to the association to prevent head-of-the-line
blocking". Well, mapping diameter messages into different SCTP streams
could be one way to prevent HOL blocking but some increase of
processing delay might be incurred. However, sending every Diameter
message via the SCTP Stream ID zero with the “unordered” flag set may
lead to improved performance and simplicity.
I'd suggest something like: "Diameter messages need to be mapped into
SCTP streams in a way that avoids Head Of the Line (HOL) blocking.
Among the different ways of performing the mapping that fulfill this
requirement, the simplest alternative is proposed; a Diameter entity
SHOULD send every Diameter message (request or response) 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.
Although both sides of the SCTP association SHOULD use stream 0 for
Diameter requests and responses if they follow this recommendation, if
a Diameter request arrives over a particular stream, the server is
free to return responses over a different stream.  This way, both
sides manage the available streams in the sending direction,
independently of the streams chosen by the other side to send a
particular Diameter message.  This avoids undesirable collisions when
seizing a particular stream". This is how SIP over SCTP works.

-SECURITY MECHANISMS-

3) According to draft-ietf-dime-rfc3588bis, the use of a secured
transport for exchanging Diameter messages is mandatory, being TLS the
primary method and IPsec a
secondary alternative.  However, it is assumed that TLS is run on top
of TCP when it is used, leaving IPsec as the only mechanism to secure
Diameter messages. Is that the expected outcome?

4) TLS over SCTP usage: As exposed in draft-ietf-tsvwg-dtls-for-sctp,
TLS over SCTP (RFC3436) has some serious limitations. In order to
overcome these limitations, I believe Diameter over DTLS/SCTP shall be
proposed as an alternative to TLS/SCTP. To my best knowledge, the IESG
has recently approved DTLS over SCTP as a Proposed Standard and it
will be published as a Standards Track RFC. However, I'd agree that
until DTLS/SCTP gets widely adopted by the industry, we'll find IPsec
as the common deployed mechanism to secure Diameter messages (please,
see comment 6).

5) If draft-ietf-tsvwg-dtls-for-sctp gets adopted as a security
mechanism for Diameter:

5.1) it should be documented somewhere that no SCTP identifier needs
to be defined for Diameter messages over DTLS. Therefore, the Payload
Protocol Identifier in SCTP DATA chunks transporting DTLS-based
Diameter messages MUST be set to zero
5.2) a port number should be assigned
5.3) the S-NAPTR Application Protocol Tag for DTLS/SCTP (say,
diameter.dtls.sctp) should be registered

6) Diameter over SCTP over IPsec usage: I believe some guidelines on
this would be beneficial. Would it be ok to create an association and
SPD selector for each SCTP IP Address and port involved in an
association, treating SCTP as any other layer above IP, and thus
potentially creating multiple entries for a single SCTP association?
IMO implementations MUST at least support this mode (if they support
Diameter over SCTP over IPsec). I believe RFC3554 (SCTP with IPsec) is
unnecessary for Diameter applications, both because of the relatively
low number of Diameter connections per system, and because one of the
main advantages of SCTP is multi-homing across interfaces which makes
RFC3554 potentially impossible to implement.

I'm planning to put these ideas together in a short draft, but would
like to hear your take on them.

Many thanks in advance,

Victor Pascual

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 22 Oct 2010 14:16:16 +0900

Hello Victor,

I find your comments very useful. From an implementor point of view, the
current draft leaves a lot of unclear aspects on how the SCTP transport
should be implemented, and this will surely result in many
un-interoperable choices.

2) IIUC, the unordered delivery is not compatible with TLS/SCTP.
Therefore, if this recommendation is made, TLS/SCTP (which is clearly a
resource-killer) should be deprecated at the same time (as you highlight
in 4) )

3) In addition to what you show, the document also recommends SCTP over
TCP... This is quite contradictory...

5.2) I believe the same port as Diameter / TLS / TCP could be used,
right? Or is this too confusing?

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 22 Oct 2010 08:52:52 +0200

Hi Sebastien,

thanks for your feedback! Please find some notes inline.

On Fri, Oct 22, 2010 at 7:16 AM, Sebastien Decugis <[email-masked]> wrote:
(snip)
> resource-killer) should be deprecated at the same time (as you highlight

Lack of support for unordered delivery is just one of the limitations
of TLS/SCTP. Some others are documented in
draft-ietf-tsvwg-dtls-for-sctp-06

> TCP... This is quite contradictory...

IIRC it is assumed that TLS is run on top of TCP when it is used

Cheers,
-- 
Victor Pascual Ávila