Subject: [NSIS] SCTP for GIST draft comments

From: Andrew McDonald <[email-masked]>
Date: Sat, 19 Aug 2006 13:32:22 +0100

Hi all,

This draft is a good start at defining the use of SCTP as an MA protocol
for GIST. I have, however, got a number of comments and questions.

General:

I understand that the document is meant to be about using SCTP with or
without the partial reliability (PR-SCTP) extension. However, some parts
seemed to assume that PR-SCTP was used and some bits assumed that plain
SCTP was used (e.g. TLS discussion). Some clarification is probably needed.

In the abstract and/or introduction I had expected to see the GIST term
'messaging association', but it instead talks only about 'connection
mode operation'.

The introduction makes a couple of claims, which I didn't see backed up
in the document, e.g. "the GIST transport protocol must accommodate
flexible retransmission" (must, even if not capitalised, seems strong -
is the 'must' part of an argument that there is something wrong with the
base spec? - I don't think that is the intended meaning), "a number of
functions that are desirable for signaling transport, such as multiple
streams and multiple IP addresses". I assume some of this will be
covered by the 'appplicability statement' mentioned in the slides from
Montreal.

The introduction says that this document covers:
1) how to use the multiple streams feature of SCTP.
2) how to handle the message oriented nature of SCTP.
3) how to take the advantage of multi-homing support of SCTP.

Is (2) simply covered by the statement that SCTP fragmentation needs to
be supported? (does that need to be a MUST?) Or, is it expected that
some further text will be added on this topic?

I assume that (1) and (2) are still 'TBD' for a future version of this
draft.

SCTP Parameters:

As well as the SCTP port number, the MA-Protocol-Options also negotiates
an Initial RTO value and a Maximum RTO value. It is not clear to me why
this is done, or even necessary. Similar options aren't negotiated in
the MA-Protocol-Options for TCP.

It is also not clear that SCTP intends these to be negotiated options.
If they were meant to be negotiated, why aren't they part of the SCTP
handshake? The SCTP API draft (draft-ietf-tsvwg-sctpsocket-13.txt) does
allow these parameters to be set on a per-association basis, but this
doesn't mean that GIST needs to get involved in negotiating them.

It might also be useful to more closely follow the format used for the
definitions of Forwards-TCP and TLS in the GIST draft, e.g.
>   o  in a Query: no information apart from the field header.
>
>   o  in a Response: 2 byte port number at which the connection will be
>      accepted, followed by 2 pad bytes.

Also some discussion probably needs to be given about transfer
attributes (c.f. the Reliable=True discussion for TCP).

Multi-streaming:

A constraint currently not mentioned, is that all messages for a
particular Session ID need to be sent down the same SCTP stream. This is
necessary in order to retain the NSLP assumption of in-order delivery
(GIST section 3.5).

SCTP defines unidirectional streams (e.g. there can be a different
number of streams from A to B than from B to A). The TLS over SCTP
defines the concept of a bidirectional stream (the pair of streams
between A and B with the same stream number in both directions). Should
GIST be looking to use streams in a similar bidirectional way, or can we
be more flexible than that?

Would I be right to assume that multiple sessions will be mapped on to a
single stream? Is there any further guidance we might want to give in
that regard?

Is there any further guidance we need to give on Messaging Assocation reuse?

Multi-homing:

It is not clear that to me multi-homing is an SCTP feature we would want
to use for GIST.

Opening an SCTP association with multiple endpoint addresses doesn't
appear to be an obvious thing to do with GIST. The use of the Add-IP
extension might conceivably be something that could be considered as
part of MA reuse. However, I'm not clear why you'd want to use this.

TLS usage with SCTP:

TLS is used per-stream with SCTP. This means that a TLS handshake (or
abbreviated handshake using session resumption) needs to be performed on
each bidirectional stream.

Would we want to mix TLS and non-TLS streams in a single SCTP assocation
when using it with GIST?

DTLS usage with PR-SCTP:

TLS, obviously, won't work with partially reliable streams since it
expects a reliable transport (and has some other limitations too). There
is a draft on DTLS usage with PR-SCTP that was presented in the TLS
working group meeting in Montreal (draft-tuexen-dtls-for-sctp-00.txt,
presentation at
http://www3.ietf.org/proceedings/06jul/slides/tls-5.pdf). It is not as
trivial as it might sound since it also requires the use of SCTP-AUTH
(to avoid spoofed acks which indicate data has been delivered when it
hasn't). There is still an open issue of how to establish the shared
secret SCTP-AUTH using DTLS.

Once DTLS over SCTP is defined, there might be an argument that this
should be used as the way to do TLS over both PR-SCTP and plain SCTP
(since it will work in both reliable and partial reliable cases).

IANA Considerations:

Do we also need to be allocated an SCTP Payload Protocol Identifier?
(Might particularly need if mixing TLS and non-TLS traffic?)

References:

Should [5] (PR-SCTP) and [7] (TLS over SCTP) be normative rather than
informative?

I hope those comments help.

best regards,

Andrew

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis