Skip to main content

11. Security Considerations

This chapter discusses SCTP protocol security issues, potential threats, and corresponding protection mechanisms.

11.1. Security Objectives​

SCTP's primary security objectives include:

11.1.1. Integrity Protection​

Checksum Mechanism:

- Uses CRC32c checksum to protect entire SCTP packet
- Detects transmission errors and malicious tampering
- Stronger than TCP's 16-bit checksum

Verification Tag:

- Each SCTP packet contains 32-bit verification tag
- Prevents packet forgery and injection attacks
- Exchanged during association establishment

11.1.2. Availability Protection​

Cookie Mechanism:

- Prevents SYN flood attacks
- Server-side stateless
- Delays resource allocation

Multihoming Support:

- Provides path redundancy
- Enhances denial-of-service resistance
- Automatic failover

11.1.3. Confidentiality​

Note: SCTP itself does NOT provide data encryption.

Recommendations:

  • Use TLS over SCTP (RFC 3436)
  • Use DTLS over SCTP
  • Use IPsec

11.2. SCTP Responses to Potential Threats​

11.2.1. Masquerade Attacks​

Threat: Attacker pretends to be legitimate endpoint.

SCTP Protection:

1. Verification Tag Validation
   - Each packet must contain correct verification tag
   - Tag exchanged during association establishment
   - Packets with incorrect tag discarded

2. Four-way Handshake
   - INIT -> INIT ACK -> COOKIE ECHO -> COOKIE ACK
   - Validates peer's address
   - State Cookie contains encrypted information

State Cookie Contents:

- Peer's verification tag
- Peer's initial TSN
- Timestamp
- Lifetime
- HMAC signature

11.2.2. Replay Attacks​

Threat: Attacker captures and replays valid SCTP packets.

SCTP Protection:

1. TSN (Transmission Sequence Number)
   - Monotonically increasing
   - Detects duplicate packets
   - Window mechanism prevents old packets

2. Cookie Lifetime
   - State Cookie contains timestamp
   - Expired cookies rejected
   - Prevents INIT ACK replay

3. Verification Tag
   - Unique per association
   - Invalidated after association termination
   - Prevents cross-association replay

11.2.3. Denial of Service Attacks​

11.2.3.1. SYN Flood Type Attacks​

Threat: Attacker sends numerous INIT chunks, exhausting server resources.

SCTP Protection - Cookie Mechanism:

1. Receive INIT
   - Do not allocate TCB
   - Do not allocate resources
   - Generate State Cookie

2. State Cookie
   - Contains all information needed to establish association
   - Protected by HMAC
   - Send INIT ACK (containing Cookie)

3. Receive COOKIE ECHO
   - Verify Cookie's HMAC
   - Check Cookie lifetime
   - Only then allocate TCB

Advantages:
- Server-side stateless
- Attacker must receive INIT ACK
- Difficult to perform source address spoofing

Recommended Cookie Generation Algorithm:

Cookie = HMAC(Secret, Peer-Address | Peer-Port | My-Tag | 
               Peer-Tag | Timestamp | ...)

11.2.3.2. Packet Flood Attacks​

Threat: Attacker sends numerous packets, exhausting bandwidth or processing capacity.

SCTP Protection:

1. Verification Tag Filtering
   - Quickly discard packets with invalid tags
   - Minimize processing overhead

2. Checksum Verification
   - Early detection of corrupted or forged packets
   - Avoid subsequent processing

3. Congestion Control
   - Limits sending rate
   - Prevents network congestion

11.2.3.3. Multihoming Exploitation Attacks​

Threat: Attacker abuses multihoming functionality for attacks.

Scenario: Attacker includes victim's address in INIT, causing server to send traffic to victim.

SCTP Protection - Address Verification:

1. HEARTBEAT Verification
   - Send HEARTBEAT to new address
   - Wait for HEARTBEAT ACK
   - Only use new address after confirmation

2. Address Parameter Handling
   - Do not trust all addresses in INIT
   - Primarily use source address
   - Other addresses require verification

3. Implementation Recommendations
   - Limit number of addresses that can be added
   - Apply rate limits to unverified addresses
   - Log suspicious behavior

11.2.4. Eavesdropping​

Threat: Attacker monitors SCTP communications, stealing sensitive information.

SCTP Limitation:

SCTP itself does not provide encryption
- Data transmitted in plaintext
- Requires additional security layer

Recommended Solutions:

1. TLS over SCTP (RFC 3436)
   - Application layer encryption
   - Suitable for stream-oriented applications

2. DTLS over SCTP
   - Datagram encryption
   - Suitable for message-oriented applications

3. IPsec
   - Network layer encryption
   - Transparently protects all SCTP traffic
   - ESP mode provides confidentiality and integrity

11.2.5. Blind Attacks​

Threat: Attacker sends forged packets without monitoring traffic.

Difficulty Factors:

1. Must Guess
   - Correct verification tag (32 bits)
   - Correct source and destination ports
   - Correct TSN range

2. Success Probability
   - Verification tag: 1/2^32
   - Plus TSN verification: even lower

3. SCTP Response
   - Incorrect packets silently discarded
   - No feedback provided to attacker
   - Difficult to perform brute force attack

Special Protection - ABORT and SHUTDOWN COMPLETE:

These chunks can set T bit:
- T=1: Use verification tag from received packet
- Allows response to "Out of the Blue" packets
- But strictly limited to prevent abuse

11.3. SCTP Interactions with Firewalls​

11.3.1. Firewall Challenges​

State Tracking:

Firewalls need to understand SCTP state machine:
- CLOSED
- COOKIE-WAIT
- COOKIE-ECHOED
- ESTABLISHED
- SHUTDOWN-PENDING
- SHUTDOWN-SENT
- SHUTDOWN-RECEIVED
- SHUTDOWN-ACK-SENT

Multihoming Handling:

Challenges:
- Single association may use multiple IP addresses
- Traffic may come from different source addresses
- Dynamic address addition/removal

Solutions:
- Track associations rather than individual connections
- Identify verification tag pairs
- Allow address changes within association

11.3.2. Firewall Recommendations​

Basic Filtering Rules:

1. Verify SCTP Checksum
   - Discard packets with checksum errors
   - Mitigate certain attacks

2. State Tracking
   - Only allow valid state transitions
   - Reject invalid chunk combinations

3. INIT Handling
   - May require rate limiting
   - Prevent INIT floods

4. Multihoming Support
   - Allow ASCONF chunks (if supporting dynamic addressing)
   - Verify HEARTBEAT exchanges

Recommended Configuration:

Allow Outbound:
- INIT, COOKIE ECHO, DATA, SACK, HEARTBEAT, SHUTDOWN
- Other control chunks

Allow Inbound:
- INIT ACK, COOKIE ACK, DATA, SACK, HEARTBEAT ACK, SHUTDOWN ACK
- Chunks responding to established associations

Block:
- Invalid state transitions
- Unsolicited INIT ACK
- Packets with incorrect verification tags

11.3.3. NAT Considerations​

NAT Issues:

SCTP contains IP address information:
- Address parameters in INIT and INIT ACK
- Addresses in ASCONF chunks
- NAT needs to understand and rewrite these

Challenges:
- Requires Application Layer Gateway (ALG)
- Increases NAT complexity
- May affect multihoming functionality

Recommendations:

1. Avoid including private addresses in INIT
2. Use public addresses or NAT traversal techniques
3. Consider using SCTP-aware NAT/ALG

11.4. Protection of Non-SCTP-Capable Hosts​

11.4.1. Problem​

Scenario: Attacker uses SCTP INIT to attack non-SCTP-capable hosts.

Impact:

- Target host may not understand SCTP
- May send ICMP error responses
- Attacker may exploit this for amplification attacks

11.4.2. SCTP Behavior​

Receiving ICMP Errors:

SCTP endpoints should:
1. Log ICMP errors
2. May mark path as unreachable
3. Should not immediately abort association
4. Continue trying other paths (if multihomed)

Rate Limiting:

SCTP implementations should:
- Limit INIT sending rate to single destination
- Avoid participating in amplification attacks
- Implement exponential backoff

11.4.3. Network Protection​

Recommendations:

1. Ingress Filtering
   - Prevent source address spoofing
   - BCP 38 (RFC 2827)

2. Egress Filtering
   - Limit SCTP traffic to non-SCTP ports
   - Protect legacy systems

3. Host Firewalls
   - Discard packets of unsupported protocols
   - Do not send ICMP responses (or rate limit)

Summary​

SCTP security mechanisms:

  1. Verification Tag: Prevents forgery and blind attacks
  2. Cookie Mechanism: Prevents SYN flood type attacks
  3. CRC32c Checksum: Detects tampering and errors
  4. Address Verification: Prevents multihoming abuse
  5. Four-way Handshake: Enhanced authentication

Security Limitations:

  • Does not provide encryption (requires TLS/DTLS/IPsec)
  • Does not provide source authentication (requires upper layer mechanisms)

Best Practices:

  • Use encryption layer to protect sensitive data
  • Implement rate limiting and monitoring
  • Properly configure firewalls and NAT
  • Follow secure coding practices
  • Apply security updates promptly
Last updated on