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

[Randy Stewart <[e-mail]>]

On Feb 5, 2013, at 5: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. 
> 
>>> 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.
> 
>>> 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. 

It sounds to me that we need another document besides this. Maybe
taking this document and mention as Pete said you could
use the assigned port as an example but other scenarios are possible
but not described here.

This whole document started when I built the tunneling ability into
the FreeBSD stack and we originally only setup the SCTP assigned port. Of
course for kernel land its now sysctl'able.. and can be changed… but
it gets a lot more dicy when you are doing multiple user stacks (as the
detailed discussion here shows ;-D)


R


> -- 
> [e-mail]
> 

-----
Randall Stewart
[e-mail]