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

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 2 Nov 2010 11:54:10 +0100

Any additional comment on this?

On Thu, Oct 21, 2010 at 5:27 PM, Victor Pascual Avila <
[email-masked]> wrote:

> 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
>

-- 
Victor Pascual Ávila

---

From: <[email-masked]>
Date: Tue, 2 Nov 2010 15:44:43 +0100

Hi Victor pascual,
 
Just to let you know that your mail has been considered and this point will be addressed during the DIME WG meeting the next week.
Of course, it doesn't preclude further exchange on the mailing list meanwhile.
 
Lionel

________________________________

	De : [email-masked] [mailto:[email-masked]] De la part de Victor Pascual Avila
	Envoyé : mardi 2 novembre 2010 11:54
	À : [email-masked]
	Objet : Re: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport

	On Thu, Oct 21, 2010 at 5:27 PM, Victor Pascual Avila <[email-masked]> wrote:

		Hello,

		
		-SCTP USAGE-

		message via the SCTP Stream ID zero with the "unordered" flag set may
		
		-SECURITY MECHANISMS-

		

		
		Many thanks in advance,
		
		Victor Pascual

	-- 
	Victor Pascual Ávila