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

From: Michael Tuexen <[email-masked]>
Date: Sat, 2 Feb 2013 18:29:16 +0100

On Jan 31, 2013, at 11:37 AM, Tero Kivinen wrote:

> 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.
> 
>>>>> Also what if host A and B already have one SCTP connection, and now
>>>>> host B wants to create another, do host B reuse the same UDP
>>>>> destination port number for host A that was used for the already
>>>>> existing SCTP connection between them? The section 4.1 says that UDP
>>>>> port numbers are stored per destination address per SCTP association,
>>>>> so that would indicate no.
>>>> 
>>>> As stated in the document, each stack uses a single port number
>>>> as the destination address of all incoming packets.
>>> 
>>> The document also says:
>>> 
>>>  Using a single UDP encapsulation port number per host is not
>>>  possible if the SCTP stack is implemented as part of an
>>>  application.
>>> 
>>> which indicates that using multiple UDP port numbers is also an
>>> option. Or is implementing SCTP stack as appliction out of scope too?
>>> Section 3.1 seems to indicate that it is not out of scope.
>> 
>> No, you can implement SCTP in the kernel (which means that the stack
>> is unique on the host) or in the application (which means there
>> can me multiple, one stack per association for example).
> 
> 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?
> 
> This seems to give bit mixed signals what is supported and what is
> not. 
> 
>>> From the section 3.1 and 4.1 it is not really clear what needs to be
>>> supported. If I have understood correctly that if SCTP is implemented
>>> in kernel then we use one UDP port for the whole host, but if SCTP is
>>> implemented by the application then each application might have
>>> different UDP port, i.e. there will be multiple UDP SCTP encapsulation
>>> ports in the host.
>> Correct.
>>> 
>>> I.e. if host A is connected to two different applications on host B.
>>> Host B is such host that it does not support SCTP on kernel, the SCTP
>>> is implemented on the application itself, and that means each
>>> application has separate UDP encapsulation port. Now what you said
>>> before I assume that it is outside the scope of this document for host
>>> A know how to connect to host B, i.e. how to get the UDP port numbers
>>> where to connect, and also whether to use the UDP encapsulation at
>>> all?
>> Correct. Finding the remote UDP number for the initial packets is
>> out of scope.
> 
> 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.

I hope I made the scope clearer by adding the above sentence to the
abstract.
>>> Is there any work ongoing on this? I.e. how is this going to be solved
>>> in practice? Or is it assumed that the SCTP applications which do not
>>> have direct access to IP-layer, which need to use UDP encapsulation
>>> because of that, are always only initiators, i.e. nobody ever connects
>>> to them, they always initiate the connection to the known services?
>> As said above, a complete solution is out of scope of this document.
> 
> That is fine, but it should mention what is out of scope. 
Hopefully addressed by the suggested change.
> 
>>>>> In some cases also the IP-address might change,
>>>>> i.e. if the NAT box is rebooted or its connection table is cleared,
>>>>> and the NAT box have multiple IP-addresses, it is completly possible
>>>>> that the NAT mapping changes so that IP-address and UDP port number
>>>>> both change. I am not familiar enough with SCTP to know whether this
>>>>> causes problem with SCTP, i.e. whether it is default SCTP rules to use
>>>>> the last seen IP-address when sending reply or what.
>>>> 
>>>> The method described in the document does NOT cover changing the
>>>> address. If you want to handle that, you need to use the address
>>>> reconfiguration extension (RFC 5061).
>>> 
>>> Then you need to say that in the draft. Note, that hosts A and B do
>> 
>> It is mentioned in the last paragraph of section 4.7
> 
> I would be very suprised if someone can really combine RFC5061 and
> this document to get interoperable implementation with just that one
> reference, in the cases where the NAT box is rebooted and the outer
> IP-addresses change because of that.
Hmmm. This document only covers the UDP encapsulation part. It is not
intended to extend RFC 5061.
> 
>>> not have any way of knowing when the IP-address changes, or whether it
>>> is going to change. For normal TCP (and most likely also SCTP) this
>> 
>> Well, that depends.
> 
> No, it really does not. We are not talking about local IP address
> changes, we are talking the NAT box rebooting and loosing state, and
> allocating new IP address for the UDP encapsulated SCTP packets. The
> local host does not know anything about that. 
OK. Let us consider this case.
> 
>> If the address change is local on the host, SCTP kernel implementations (at
>> least FreeBSD and Linux) will get notified when addresses are added or
>> removed. For example, on FreeBSD you can add an address using
>> ifconfig and the address changes will happen on all association which use
>> a wildcard bound SCTP socket, it is allowed system-wide via the
>> net.inet.sctp.auto_asconf sysctl and the application didn't disabled
>> it via the SCTP_AUTO_ASCONF socket option.
> 
> We are not talking about local changes.
> 
>> On the other hand, if the address change is not local, the peer will
>> respond to a packet with an ABORT chunk having the T-bit set. This
>> could be interpreted as an indication of an address change. 
> 
> Ok, so this is already handled in the SCTP internally, i.e. remote
> node notices that other end changed IP-address and indicates that to
> the other end. Mentioning this in the draft would most likely help for
> implementors to understand what they need to do in this cases.
See the suggestion below.
> 
> NAT boxes loosing state is something that should be explained in the
> draft, as that is quite common situation and if this is supposed to
> work on environments where there are NATs, then what happens when NAT
> box looses state should be explained.
> 
>>> IP-address change will usually result the connection to be reset, as
>>> the NAT box does not have the mapping for the connection anymore, but
>>> for UDP that does not happen. The NAT box will just create new
>>> mapping.
>> Which is fine.
>>> 
>>> I.e. the situation is as follows. Host A is behind NAT, and talks to
>>> host B using UDP encapsulated SCTP. Now the NAT box is rebooted, and
>>> it looses state. When Host A sends next UDP encapsulated SCTP packet
>>> to Host B that UDP packet might get new source IP address by the NAT
>>> box. What should happen at that point?
>> As described above, host B will respond with an ABORT chunk and host A
>> can use this as an indication that it has to update its address.
>> So it can send a ASCONF chunk adding the wildcard address and removing
>> the wildcard address which will result in the possibility to continue
>> the association.
> 
> Adding section explaining the thing above would most likely help to
> understand that this issue needs to be handled in the implementations.
> This for example makes it quite clear that using udp encapsulation
> through NAT without supporting RFC 5061 is just not going to work. 
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.
> 
>>> Should the SCTP implementation notice that IP-address of the
>>> association has changed, and send some kind of reset or what? Or does
>>> the SCTP implementation just drop all packets because they do not
>>> match association and then connection is dropped after timeout?
>>> 
>>> How do you plan to use RFC 5061 to solve that situation? I do not know
>>> enough of RFC 5061 to say how it can be used to solve this kind of
>>> situation, where the peer A whose IP-address was changed does not even
>>> know that his IP-address was changed.
>> I hope the above makes it clearer. We can add at the end of section 4.7
>> text like:
>> 
>> If an SCTP end-point receives an ABORT with the T-bit set, it MAY
>> use this as an indication that the addresses seen by the peer might
>> have changed.</t>
> 
> 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.
> 
>>> Of course as the NAT mappings are usually remote IP + remote port +
>>> protocol + NAT IP + NAT port, this means that changes for host C to
>>> get exactly same 5-tuple are small... On the other hand host C can
>>> most likely know remote IP and remote port as they are well known
>>> based on the service. The NAT IP is most likely going to be same all
>>> the time, so only thing host C needs to be doing is to cause NAT to
>>> loose state (i.e. cause it to either reboot, or run out of mappings),
>>> and then start filling up the NAT mappings until it gets the NAT port
>>> host A used earlier.
>>> 
>>> One way to cause NAT to loose state, is to start flooding NAT with new
>>> UDP packets each destinationed to remote host + port and having
>>> UDP different source port. NAT will allocate new NAT port for each of
>>> them until it runs out of port numbers, in which case it starts
>>> reusing port numbers. Now depending on the NAT implementation, flood
>>> guarding, SCTP heartbeat intervals etc NAT might reuse the host A's
>>> port in which case host C managed to get the session.
>> 
>> Yes, that is possible. What can the attacker do? The attacker can't
>> insert any DATA or SACK chunks, since it would have to guess the
>> V-tag. However, the attacker can ABORT the association with sending
>> an ABORT with the V-tag set. But this is not better or worse than
>> attacking the NAT box. So most likely the attacker can receive an
>> RWND of user data. If sent unprotected, I would assume that his is
>> acceptable. Using DTLS/SCTP would protect against it.
> 
> It can do exactly same things it can do in the other case where the IP
> address got reused. It will receive all packets that were supposed to
> be received by original host A, so it can see all traffic going to
> host A. As there is no cryptographic checksums there, it can add data
> to the packets it receive and might send them to host A depending on
> the network layout. At least as far as I know.
Sure, if the attacker can forward the packets to the end-point from
which it took over the address, the attacker is a true man-in-the-middle.
> 
>>> Which ways those HEARTBEAT messages are sent? For NAT mappings to stay
>>> alive, the messages quite often needs to be coming from inside of the
>>> NAT, i.e. from the host which is behind the NAT, and if both ends are
>>> behind NAT, they need to be coming from both ends. Do HEARTBEATs cover
>>> that possibility. Also some NAT boxes are known to require as small
>>> keepalive intervals as 20 seconds... How often do you send HEARTBEATS?
>> Both sides send HEARTBEATs, the standard time between them is 30 seconds
>> plus RTO plus/minus 50%. However, the application can change the 30 seconds
>> to other values using the standard socket API.
> 
> Ok, so that is ok. 
> 
>>> So is having both ends behind NAT out of scope? This should then be
>>> mentioned in section 3.2. Note, that similar problems also arise when
>>> you need to connect to host which is behind NAT, i.e. even if it is
>>> only one host behind NAT, but if the connection is coming from the
>>> outside, you have similar problems than what you have when both ends
>>> are behind NAT.
>> 
>> I think the point is that finding the remote port number for initial
>> packets is out of scope of the this document.
> 
> The dynamic port fixup is UNSAF operation, already described in the
> draft.
> 
> The use if RFC5061 with wildcard addresses is similar operation. Both
> of those are solutions which get around the fact that peers do not
> know the actual addresses, i.e. are trying to "determine or fix the
> addresses by which it is known to another endpoint".
> 
> UNSAF operations are not only the cases where you try to find out the
> initial address, it covers also all cases where the protocol tries to
> fix things caused by NATs. From RFC3424:
> 
>   o  proposed workarounds include the use of "ping"-like address
>      discovery requests sent from the UNSAF client (initiator) to the
>      UNSAF server (listener), to which the listener responds with the
>      transport address of the initiator - in the address realm of the
>      listener.  However, with connection-less transports, e.g. UDP,
>      IPsec ESP, etc., an UNSAF process must take care to react to
>      changes in NAT bindings for a given application flow, since it may
>      change unpredictably.
> 
> just covers this loosing NAT bindings and the:
> 
>   o  limiting the scope to outbound requests for service (or service
>      initiation) in order to prevent unacceptable security exposures.
> 
> 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.
> 
> 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...

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'm not completely understanding issue (2). So it would be helpful
if you could describe the potential attack a bit more.

Best regards
Michael 
> -- 
> [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 Feb 2013 15:24:41 +0200

> UDP port number can be used.

That is better. But see below.

> 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.

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.

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. 

> 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 hope I made the scope clearer by adding the above sentence to the

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. 

> ID, but if the IESG thinks that this should be the case, we

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.

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. 

>   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). 

> 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... 

> I'm not sure what you are requesting here...

UNSAF considerations is separate issue to the other issues we have
there. 

> 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. 

> 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.
-- 
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Feb 2013 15:31:09 +0100

> to be multiple applications each supporting SCTP. How is he trying to
He simply can't assume that he is able to bind a particular UDP port.
> selects solution B to the same problem they are not going to
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 architecture is written down before the technical bits are
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 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.
> 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.
> 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).
> 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.

> But before going to those it would be much better to know what is the
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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Feb 2013 12:47:31 +0200

> 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. 

> 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. 

> 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.

> 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. 
-- 
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 5 Feb 2013 12:59:46 +0100

> the security really hard. 
Understood.
> explaining how it is used there, and analyze the security in that
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.
> not see the whole system, I can only see one piece (the SCTP stack
Understood. Maybe the scope mentioned above would be acceptable?
> architectures are possible using these documents. 
That would make sense.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Tue, 5 Feb 2013 06:12:49 -0500

> 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

-----
Randall Stewart
[email-masked]