Re: Starting WGLC on draft-ietf-nsis-ntlp-sctp-05.txt
Roland Bless <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Organization | Institute of Telematics, University of Karlsruhe |
| Message-ID | <[email protected]> |
Hi Martin and all,
Martin Stiemerling wrote:
> draft-ietf-nsis-ntlp-sctp-05.txt
> General Internet Signaling Transport (GIST) over SCTP.
>
> The WGLC will run for three weeks to get time for all WG members to do a review of the draft.
>
> The draft is here:
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-05.txt
>
> The WGLC will end Feb 16th 10am CET.
Finally I've managed to read the draft, but I'm one day too late with my
comments (sorry!). Nevertheless, here they are:
Section 1:
* In the introduction:
- not clear whether one should also mention
the advantage of message-oriented transport by SCTP instead of
using the byte stream oriented TCP where one must provide its own
framing mechanisms.
- not clear at the end of the 2nd paragraph whether DTLS over SCTP
is also in scope of the draft or not.
* typo s/extention/extension
* PR-SCTP seems to be contradicting to the C-mode (reliable) transport
requirements of GIST at first. This must be clarified.
Section 2:
SCTP Association: it could be mentioned in parentheses that the
transport addresses also contain the port number (same remark
as in RFC 4960) or that for an SCTP endpoint the following holds:
All transport addresses used by an SCTP endpoint must use the same
port number, but can use multiple IP addresses. A transport
address used by an SCTP endpoint must not be used by another SCTP
endpoint. In other words, a transport address is unique to an
SCTP endpoint.
Section 3.1.1:
TLS as protocol specifier is not useful alone. It can only be specified
together with another protocol, e.g., Forwards-TCP+TLS.
Section 3.1.2:
"The destination information MUST..." it is not very clear which
destination information is meant, should be clarified that the
destination for establishing the SCTP association is meant here
(or SCTP endpoint destination).
Section 3.3.:
It should be clarified under which circumstances the reliability
requirements for GIST C-mode messages are still met when PR-SCTP
is used. As far as I understood, the "timed reliability"
service is only one potential/special use case of PR-SCTP.
Section 5.1:
To me it makes sense for the path-coupled MRI to limit the available
SCTP transport addresses to exactly the one from the NLI, so that
only this IP address is used for establishing the SCTP association.
This should also be mentioned in Section 3.1.2.
Section 6:
"For securing _a_ GIST over SCTP channel"
A little bit too short to discuss DTLS over SCTP. Forwards-DTLS
should be mentioned and motivated and why TLS+SCTP would be different.
It is not clear to me whether DTLS over SCTP is still "reliable".
DTLS would qualify as being secure but not reliable (GIST would require
to establish an MA for this, but I guess it also implies C-mode =>
reliability?).
And finally:
What about NAT traversal issues with SCTP? IMHO there should be a short
section on discussing this. Can one simply use the NAT traversal object
of GIST etc.? Is there anything special?
Regards,
Roland