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

[Michael Tuexen <[e-mail]>]

On Feb 4, 2013, at 2:24 PM, Tero Kivinen wrote:

> Michael Tuexen writes:
>>> Michael Tuexen writes:
>>>>> It might be good to say that in the document, i.e. that it is out of
>>>>> scope of this document. 
>>>> 
>>>> What about adding
>>>> <t>Please note that this document does not provide all techniques necessary
>>>> for building a complete NAT-capable application using SCTP. This document
>>>> focuses on the functionality required within the SCTP stack and making
>>>> this available via an API.</t>
>>>> to the Abstract?
>>> 
>>> I think it would be better to add more explicit notice what is left
>>> outside of the scope. 
>> 
>> So what about adding in addition to the above:
>> 
>> It does not cover mechanism to determine whether UDP encapsulation is
>> required to reach the peer and, if UDP encapsulation is used, which remote
>> UDP port number can be used.
> 
> That is better. But see below.
> 
>>> That was my understanding, and thats why it was bit odd to see text
>>> that says that you have one UDP port only, and it is not possible to
>>> do that if SCTP stack is in the application.
>> 
>> The above text was changed while addressing other IESG comments to
>> 
>> Using a single UDP encapsulation port number per host is not possible
>> if the SCTP stack is implemented as part of each application,
>> and there are multiple applications.
>> 
>> Does that make things clearer?
> 
> It makes it bit clearer, but there is still the same problem. It is
> really hard to try to understand what should be done when the document
> just says "it is not possible". What is implementor trying to
> implement this document doing when he is trying to implement SCTP as
> part of application. He does not have any idea whether there are going
> to be multiple applications each supporting SCTP. How is he trying to
> solve this issue.
He simply can't assume that he is able to bind a particular UDP port.
> 
> This document seems to be only covering some small technical bits, but
> the overall architecture picture is completely left out, which makes
> it very hard to make interoperable implementations. If one implementor
> reads the text above and selects solution A and another implementor
> selects solution B to the same problem they are not going to
> interoperate.
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.
> 
> It almost seems like this is missing the scenarios and uses cases
> document. In the UDP Encapsulation of IPsec ESP Packets (RFC3948) we
> had RFC 3715 which covered the use cases and RFC3947 (how the
> negotiation is done) for example said:
> 
>   This document defines a protocol that will work even if both ends are
>   behind NAT, but the process of how to locate the other end is out of
>   the scope of this document.  In one scenario, the responder is behind
>   a static host NAT (only one responder per IP, as there is no way to
>   use any destination ports other than 500/4500).  That is, it is known
>   by the configuration.
> 
> I.e it said it is out of scope of the document to explain how it
> works specifically, but gives one example which can be implemented and
> supported. 
> 
>>> Which is again one thing that should be explictly mentioned. It makes
>>> hard to understand what this document is for, as you would expect this
>>> kind of things to be solved here, or at least pointed to a pointer
>>> telling where they are solved, but this document is silent about the
>>> issue.
>> 
>> OK, I think you are expecting a complete NAT traversal solution provide
>> in the document whereas the document only addresses how to encapsulate
>> SCTP in UDP packets and how to control this via the socket API.
> 
> Mostly yes. Or at least I would expect to see pointers to other
> documents explaining the architecture and solutions for the complete
> NAT traversal solution.
> 
> If you do not know what kind of architecture you are aiming for and
> what kind of use cases you have, it is very hard to get the technical
> details right. It seems that you most likely do have an architecture
> in your mind, and the current document is designed to solve the issues
> coming from that architecture, but it would make things much better if
> the architecture is written down before the technical bits are
> published as RFC. 
I think that the document describes the SCTP related procedures and
an API to allow applications to do any kind of negotiation or even
none (just assuming 9899 at the server side).
> 
>> I hope I made the scope clearer by adding the above sentence to the
>> abstract.
> 
> 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.
> 
>> But that is not true. If you are using single-homed SCTP association
>> and you don't want to survive a reboot of NAT boxes, you don't need
>> RFC 5061. This setup is similar to TCP.
>> Using an ABORT as an indication of a NAT having rebooted and the
>> appropriate behavior is currently not specified and only needs to
>> be specified if you want to make SCTP/UDP resistant against NAT
>> reboots. Personally, I didn't see this within the scope of this
>> ID, but if the IESG thinks that this should be the case, we
>> can add this.
> 
> Whether that is added here or as separate protocol is not really an
> issue, the problem is that for the implementor implementing or the
> reader of this document does not have any idea how many this kind of
> details have been omitted from this document.
> 
> It would be fine to say that this document only scopes the case where
> the SCTP initiator is behind NAT and the responder always uses the one
> fixed port (which might be known either from the configuration or some
> protocol designed later) when connecting.
> 
> Then it would be clear what kind of situations are covered. Now it
> seems to be that this document might allow all kind of things but
> nothing is specified here so it makes it very hard for implementor to
> know what things needs to be implemented.
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.
> 
> For protocol design point it might be nice to design protocol as open
> as possible, and leave all details open as that allows all kind of
> uses for the protocol. As an implementor implementing such
> specification is really hard. The implementor needs to implement all
> corner cases which were left out from the specification, and the
> implementor needs to decide how to act when X happens even when that
> was not specified in the specifications. Now multiple implementors will
> most likely do different things when X happens, and then the
> implementations are not interoperable. 
Hmm. We have implemented this extension and we think that the document
clearly describes what you do *in* in the SCTP stack. At least I didn't
find it hard to implement it (neither does Randall, I guess).
> 
>>> I would like think it would be better to add new section explaining
>>> how this is supposed to interact with NAT boxes loosing state. I.e.
>>> the text what you explained above to me. Until now I had only assumed
>>> that if I would be implementing that, I do not need to care about
>>> RFC5061 unless I want to support IP-addresses changing. After your
>>> explination it is clear that all implementations who want to work
>>> through NATs do need to support it.
>> 
>> OK, if the IESG want this, it can be added.
>> This would require:
>> * Add specific exception for the reception of ABORTs with the T-bit
>>  set. Handle this as an indication that a NAT-box has rebooted.
>> * Add an example showing the ASCONF message exchange which is used if
>>  the end-point thinks that a NAT-box lost its state.
> 
> 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.

>>> Is just what this document does, i.e. limits the scope so that only
>>> outbound ocnnections are allowed or similar constraints, but does not
>>> mention what those constraints are.
>> 
>> I don't think we are limiting the scope to outbound associations.
> 
> As I said as I do not know what is the scope of the document, it is
> really hard to say what is needed... 
> 
>>> What you are trying to say is that UNSAF considerations do not apply
>>> as you have scoped them out, but that is exactly one UNSAF
>>> consideration. In real world case those problems do need to be solved,
>>> and this document is not really that useful if it cannot be used in
>>> real world...
>> 
>> I'm not sure what you are requesting here...
> 
> UNSAF considerations is separate issue to the other issues we have
> there. 
> 
>> An attacker can only change the UDP port number if he provides an
>> SCTP packet which can be mapped to the association. This requires
>> that the V-tag is correct. This way this mechanism is protected
>> against blind attackers the same way as the base protocol is.
>> 
>> So in summary I see two issues:
>> (1) Add text how to make SCTP/UDP resistant against state loss of NAT boxes
>> (2) Potential insufficient protection against attackers trying to
>>    change the remote UDP encapsulation port.
>> Is this correct?
>> 
>> For addressing (1), text can be added if wanted by the IESG.
> 
> I am not sure the (1) is the only thing that needs to be added. It is
> the only one I could immediately think of based on my limited
> guesswork what the scope of the document is. If the scope would be
> clear there might be other similar issues, but without knowing what is
> the actual scope of the document I cannot be sure.
> 
> For exmaple you mentioned that the scope is not limited to only
> outbound associations. That indicates there needs to be some way for
> the servers to punch holes to the NAT so the initial incoming
> connection packets comes to the host. Those hole punching mechanisms
> are now part of the security properties of the solution, i.e. if there
> is no authentication or anything, i.e. anybody behind the NAT box can
> punch or modify those holes as they like, then that would allow
> trivial way to redirect traffic to attacker. 
> 
>> I'm not completely understanding issue (2). So it would be helpful
>> if you could describe the potential attack a bit more.
> 
> It is really hard to describe the attacks when you do not know the
> architecture of the system (and I do not have enough understanding of
> the SCTP).
> 
> 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).
This document would then be part of such a document.

Best regards
Michael
> -- 
> [e-mail]
>