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

Michael Tuexen <tuexen@fh-muenster.de> Tue, 05 February 2013 11:59 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0EC21F8734; Tue, 5 Feb 2013 03:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwBMxq8VlXp5; Tue, 5 Feb 2013 03:59:49 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7221F8727; Tue, 5 Feb 2013 03:59:47 -0800 (PST)
Received: from [192.168.1.101] (p508FB80F.dip.t-dialin.net [80.143.184.15]) (Authenticated sender: macmic) by mail-n.franken.de (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 <tuexen@fh-muenster.de>
In-Reply-To: <20752.58179.975895.810541@fireball.kivinen.iki.fi>
Date: Tue, 5 Feb 2013 12:59:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A285B4C-2114-4A26-9267-895FD3C51AD7@fh-muenster.de>
References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> <20746.18802.364266.587982@fireball.kivinen.iki.fi> <0A880226-D910-403B-8D17-1AB928612E36@fh-muenster.de> <20751.46745.772166.652412@fireball.kivinen.iki.fi> <DF247660-8FCB-44F7-8039-D346CB576634@fh-muenster.de> <20752.58179.975895.810541@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1283)
Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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. 
Understood.
> 
>>> 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
Michael
> -- 
> kivinen@iki.fi
>