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

[Tero Kivinen <[e-mail]>]

Michael Tuexen writes:
> > The document should note that firewalls needs to be updated to
> > specifically inspect / filter also UDP encapsulated SCTP if they do
> > normal SCTP inspection / filtering.
> 
> I agree. What about adding the following to the Security Considerations:
> <t>Firewalls inspecting SCTP packets must also be aware of the encapsulation
> and apply corresponding rules to the encapsulated packets.</t>

That is good enough.

> > It is not clear for me how the initiator host finds the port where to
> > connect, when it is doing initial connection. I.e. if a host A wants
> > to connect to host B, which port it should use if it needs to use UDP
> > encapsulated SCTP? Is it assumed that 9899 will be used always? What
> > about connecting to the hosts which are behind NAT, i.e. if host B is
> > behind NAT, how does host A find the port number to use (which host B
> > hopefully somehow already configred to the NAT to be passed to him)?
> 
> The method for finding the remote port number for the initial packets
> is not in the scope of this document. This is something you would do
> outside of the SCTP stack. The described API provides the required
> interface for the application to set the remote encapsulation
> port.

It might be good to say that in the document, i.e. that it is out of
scope of this document. 

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

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

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?

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?

> > The draft seems to be doing dynamic port number updating based on
> > finding SCTP association (which includes checking the very weak
> > verification tag). The current section 4.4 only mentions that port
> > number is updated. 
>
> Correct.

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

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?

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.

> > The section 3.2 do say that if multiple addresses are used, then
> > RFC5061 (SCTP Dynamic Address Reconfiguration) with RFC4895
> > (Authentication Chunks for SCTP) MUST be used. With dynamic update for
> > the UDP port number, the similar hijacking attack described in the
> > RFC5061 security considerations section is applicable here too. The
> > RFC5061 requires (without using RFC2119 language) using of
> > authentication chunks to prevent that attack, so should we require
> > authentication chunks here too to prevent same attacks even when using
> > only one IP-address, as we do update the UDP ports based on the
> > received packets? Also perhaps the requirement of using authentication
>
> I don't think so. The reasoning is the SCTP/UDP/IP does not need
> to be more secure than SCTP/IP. SCTP/IP is protected against blind
> attackers by the V-tag mechanism. The same applies to SCTP/UDP/IP.
> This is described in the second paragraph of the Security Considerations.
> 
> The situation is different from changing the IP address.
> Assume that there is an association between endpoints A and B.
> If A owns IP.A while establishing the association, then looses
> it and a node C gets it, B sends packets to C. So C could take
> over the association.

And that same thing can happen with UDP encapsulation when NAT box is
rebooted. I.e host A owns IP.NAT.port-X, and then nat box is rebooted
and that port-X is given to host C, now packets sent by host B to
IP.NAT.port-X end up to host C who will be able to take over the
association.

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.

> > chunks should be also mentioned in the security considerations
> > section, as it is very important for the security point of view of the
> > protocol. 
> > 
> > The section 4.1 "Architectural Considerations" says correctly that
> > implementations needs to store remote UDP port per destination address
> > for each SCTP association, i.e. different SCTP associations can have
> > different port numbers for same destination address. This is required,
> > because there might be multiple SCTP clients behind the same NAT box
> > (having same IP-address), just using different ports. Unfortunately,
>
> And there might be multiple peer addresses and the port might be
> different. It is even possible that some peer addresses need encapsulation
> and some don't.
>
> > section 4.3 "Encapsulation Procedure" does not have the "for each SCTP
> > association" part, so it would be better to clarify this also in 4.3
> > that the UDP port number is per destination address per SCTP
> > association.
> 
> What about:
> <t>When inserting the UDP header, the source port MUST be the local UDP
> encapsulation port number of the SCTP stack,
> the destination port MUST be the remote UDP encapsulation port number
> stored for the association and the destination address to which the
> packet is sent (see <xref target='arch'/>).</t>

That seems to be ok.

> > The current draft also does not comment anything about NAT keepalives.
> > For example the RFC3948 (UDP encapsulation for IPsec) does specify
> > special NAT keepalive packets which are sent by the host behind the
> > NAT to keep the NAT mapping alive, as quite often NAT boxes remove
> > mappings after certain time. If the NAT mapping disappears, then
> > packets might not pass NAT box anymore depending on the direction of
> > packets and type of NAT box (see RFC2663 for different types of NATs).
> SCTP sends on each idle path HEARTBEAT messages which would keep the
> NAT state alive.

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?

For example RFC3948 section 4 recommends that default value for
keepalive interval is 20 seconds for UDP Encapsulation of ESP
connections. 

> What about adding the following to section 3.2:
> 
> <t>SCTP sends periodically HEARTBEAT chunks on all idle paths. These can
> be used to keep the NAT state alive.</t>

That is ok, provided HEARTBEATS are able to solve this issue.

> > The current draft does not seem to answer any of the UNSAF (IAB
> > Considerations for UNilateral Self-Address Fixing (UNSAF) Across
> > Network Address Translation, RFC3424) questions. 
>
> That is correct. However, the document describes how you encapsulate
> SCTP in UDP, not how you build a complete NAT traversal solution
> where both ends might be behind NATs. So finding the remote
> encapsulation port is not within the scope of the document.

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.

So if the scope only covers the case where the SCTP initiator is
behind NAT, then that needs to be mentioned in this document.

Also RFC3424 do also cover other cases than just those where both ends
are behind NAT... 
-- 
[e-mail]