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

[Michael Tuexen <[e-mail]>]

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
> -- 
> [e-mail]
>