Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt

Michael Tuexen <> Tue, 05 February 2013 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E0EC21F8734; Tue, 5 Feb 2013 03:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MwBMxq8VlXp5; Tue, 5 Feb 2013 03:59:49 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id D3B7221F8727; Tue, 5 Feb 2013 03:59:47 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 4EC211C0C069C; Tue, 5 Feb 2013 12:59:45 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tuexen <>
In-Reply-To: <>
Date: Tue, 05 Feb 2013 12:59:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Tero Kivinen <>
X-Mailer: Apple Mail (2.1283)
Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Feb 2013 11:59:50 -0000

On Feb 5, 2013, at 11:47 AM, Tero Kivinen wrote:

> Michael Tuexen writes:
>> From my understanding this depends on the scope. The scope of the
>> document is limited to the SCTP stack. This has been implemented
>> in a kernel stack (FreeBSD) and is also available in a userland
>> stack based on the FreeBSD kernel stack.
>> However, it does not cover how to use the API provided and therefore
>> how to build a complete application.
> The problem is that I am trying to see if there are any security
> considerations using this, and I can see a LOTS of security
> considerations depending how these other parts are done, and some of
> those do affect what is done in the SCTP stack. This makes analyzing
> the security really hard. 
>>> Scope might be clearer, but that does not solve the issue what I have
>>> with the document, i.e. it is very hard to evaluate the proposal when
>>> I do not know the architecture. 
>> If the IESG thinks it makes more sense to develop a technique for
>> encapsulating SCTP in UDP within a particular application, which also
>> covers the negotiation of the encapsulation, that is fine.
>> That would give a complete, application specific solution.
> I do not think you need to go and make application specific solution,
> but knowing what is the intended scope for this document and against
> which its security properties have been analyzed would make things
> better. 
>> Hmm. So you would prefer to limit the scope to the above (which is
>> fine with me), but that would not change the provided mechanism in
>> any way and this mechanism can be used in a wider scope.
> I would prefer have narrow scope, which makes it possible to analyze
> the security in that scope. If someone wants to use this in ways which
> are outside that scope, then someone needs to write new document
> explaining how it is used there, and analyze the security in that
> situation. 
OK. So what about servers using the IANA registered ports numbers not
behind a NAT a clients possibly behind a NAT. Does is help, if we narrow it down
to that scope. I could live with that.
>>> I think adding that would make document more usable, and would allow
>>> making interoperable implementations already based on this document,
>>> without the need of another document explaining how this is used in
>>> real world (or interop event where implementors decide and agree on
>>> the cases, and then those decisions are left as folklore in the
>>> industry, and there is no written description about it). 
>> OK. We can add that. However this only makes sense if the document
>> can proceed. If the IESG also requires to add the application level
>> NAT traversal stuff, then this becomes much more complex. I'm not sure
>> think that TSVWG has the expertise for that task.
> The IESG will do the decision anyway, I am just saying that it is bit
> hard for me to try to understand the security considerations when I do
> not see the whole system, I can only see one piece (the SCTP stack
> part) of the system.
Understood. Maybe the scope mentioned above would be acceptable?
>>> I can try to invent couple different attacks, but all of those would
>>> be depended how the bits which are left out of this document is done.
>>> But before going to those it would be much better to know what is the
>>> scope of this document.
>> hmm. I guess part of the problem is that I try to make clear that
>> the scope is limited to the SCTP stack whereas most reviewers think
>> that the scope has to include how an application will do the
>> negotiation for NAT traversal (possibly including STUN/ICE/TURN or
>> alternate solutions). 
> Yes, at least I am trying to understand how this will be used in the
> end products, and try to think security considerations of the whole
> system. 
>> This document would then be part of such a document.
> Or part of the document set, i.e. this would be perfectly fine part of
> the protocol explaining how to do things in SCTP stack, and then
> another document would tell how to do other things like negotiations
> and finding which port to talk to, and what kind of overall
> architectures are possible using these documents. 
That would make sense.

Best regards
> --