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

[Michael Tuexen <[e-mail]>]

On Jan 10, 2013, at 3:43 PM, Tero Kivinen wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
Hi Tero,

thank you very much for your comments. See my answers inline.
> 
> This document describes the UDP encapsulation for the SCTP packets.
> It seems to be quite similar to other UDP encapsulation documents (for
> example RFC3948 for IPsec). The security considerations section points
> to the RFC4960 and RFC5061 and says there is no additional security
> considerations. I belive this is not true.
> 
> The RFC4960 section 11.3 talks about the SCTP Interactions with
> firewalls, i.e. how firewalls can do SCTP filtering and how to find
> the INIT chunks. This UDP encapsulation can be used to bypass those
> checks, by encapsulating the initial INIT chunks with UDP encapsulated
> SCTP packets and then after that move to normal SCTP flow (or just
> stay in the UDP encapsulated SCTP).
> 
> This might allow bypassing the firewall rules set by the site
> adminstrator. This also might allow attacks to the hosts inside the
> firewall protected domain by bypassing the firewall, which was
> supposed to be protecting the hosts.
> 
> 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>
> 
> Also some other issues.
> 
> 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.
> 
> 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 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. In some cases also the IP-address might change,
Correct.
> 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).
> 
> 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.
> 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>
> 
> 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.

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