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. 
-- 
kivinen at iki.fi