Last Call Review of draft-ietf-tsvwg-sctp-udp-encaps-07
review-ietf-tsvwg-sctp-udp-encaps-07-secdir-lc-kivinen-2013-01-17-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-tsvwg-sctp-udp-encaps-07-secdir-lc-kivinen-2013-01-17

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.

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.

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

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.

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

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

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