Skip to content

Latest commit

 

History

History
118 lines (93 loc) · 9.05 KB

mitigations.md

File metadata and controls

118 lines (93 loc) · 9.05 KB

Mitigation Strategies Analysis for skywind3000/kcp

Mitigation Strategy: Sequence Number Enforcement (Strict)

  • Description:

    1. Initialization: Upon establishing a KCP session (ikcp_create), initialize the expected sequence number to the initial sequence number received from the peer (handled within KCP's internal state).
    2. Reception: Within the ikcp_input function (or a wrapper around it), KCP must compare the incoming packet's sequence number to its internally maintained expected sequence number.
    3. Acceptance:
      • If the sequence number matches the expected sequence number, process the packet and increment the expected sequence number (KCP's internal logic).
      • If the sequence number is within a small, pre-defined window ahead of the expected sequence number, buffer the packet (KCP's internal buffering).
      • If the sequence number is behind the expected sequence number, or significantly ahead of the acceptable window, KCP must immediately discard the packet. This should be handled within the ikcp_input function or a very closely coupled wrapper.
    4. Logging (Application Layer): The application should log any discarded packets due to sequence number violations detected by KCP. This requires either modifying KCP to provide this information or using KCP's callback mechanisms (if available) to signal such events.
    5. Window Tuning: The acceptable window size (IKCP_WND_RCV and potentially internal parameters) should be carefully tuned. This is a direct KCP configuration parameter. Start with a very small window and increase it only if necessary, monitoring for legitimate packet loss.

  • Threats Mitigated:

    • Replay Attacks (Severity: High): Prevents attackers from replaying previously captured valid packets.
    • Packet Injection (Severity: High): Makes it significantly harder to inject arbitrary packets.
    • Session Hijacking (Severity: High): Contributes to preventing session hijacking.

  • Impact:

    • Replay Attacks: Risk reduced significantly (close to elimination with a small, strictly enforced window).
    • Packet Injection: Risk reduced significantly.
    • Session Hijacking: Risk reduced significantly (part of a broader defense).

  • Currently Implemented:

    • kcp.c, ikcp_input function. Basic sequence number checking is assumed to be present (it's fundamental to KCP), but the window size might be too large.

  • Missing Implementation:

    • The application-layer logging of discarded packets (requires KCP modification or callback usage).
    • Fine-grained control and configuration of the window size (IKCP_WND_RCV) might be missing or not exposed to the application layer.
    • No mechanism for dynamically adjusting the window size based on network conditions (this would likely require KCP modifications).

Mitigation Strategy: Rate Limiting (KCP-Level, if possible)

  • Description:

    1. Ideal Scenario (KCP Modification): Ideally, KCP itself would have built-in rate limiting capabilities. This would involve:
      • Tracking incoming packet rates (per source IP, ideally, or at least globally).
      • Configurable thresholds for packet rates.
      • Discarding packets that exceed the thresholds within ikcp_input.
    2. Practical Approach (Wrapper/Application Layer): If KCP doesn't have built-in rate limiting, the application layer must implement it immediately before calling ikcp_input.
      • Maintain counters for incoming packets (per source IP, if possible).
      • Define thresholds.
      • Discard packets exceeding the thresholds before they reach ikcp_input.
    3. Connection Limit (Application Layer, interacting with KCP): The application layer should limit the number of concurrent KCP sessions (ikcp_create calls) allowed, especially per source IP. This is not directly within KCP, but it's closely related to managing KCP resources.
    4. Different Limits for Packet Types: If possible (likely requiring KCP modification), different rate limits should be applied to different KCP segment types (identified by the cmd field).
    5. Logging: Log any rate-limiting events.

  • Threats Mitigated:

    • Denial of Service (DoS) Attacks (Severity: High): Prevents packet floods.
    • Amplification Attacks (Severity: High): Reduces amplification effectiveness.
    • Resource Exhaustion (Severity: High): Protects KCP's internal resources.

  • Impact:

    • DoS Attacks: Risk significantly reduced.
    • Amplification Attacks: Risk significantly reduced.
    • Resource Exhaustion: Risk significantly reduced.

  • Currently Implemented:

    • Likely not implemented within the standard KCP library itself.

  • Missing Implementation:

    • Ideally, rate limiting should be built into KCP (ikcp_input).
    • If not, the application layer must implement rate limiting immediately before calling ikcp_input.
    • Connection limits (at the application layer, managing ikcp_create calls) are likely missing.
    • Different rate limits based on KCP segment type are almost certainly missing.

Mitigation Strategy: Congestion Control Tuning and Awareness

  • Description:

    1. KCP Congestion Control Parameters: Carefully tune KCP's congestion control parameters:
      • IKCP_WND_SND: The send window size. Start with a conservative value.
      • IKCP_WND_RCV: The receive window size (also relevant for sequence number enforcement).
      • ikcp_nodelay: This function controls several parameters related to congestion control and latency. Experiment with different settings (nodelay, interval, resend, nc) to find the optimal balance for your application and network conditions.
    2. Application-Layer Awareness: The application using KCP must monitor KCP's performance metrics (if available, possibly through callbacks or by inspecting KCP's internal state – which might require modifications). Look for:
      • High packet loss rates.
      • Increased round-trip times (RTT).
      • Frequent retransmissions.
    3. Application-Layer Response: If the application detects signs of congestion, it should reduce its own sending rate, even if KCP's internal congestion control is active. This is a crucial feedback loop.

  • Threats Mitigated:

    • Denial of Service (DoS) (Severity: Medium): Indirectly helps mitigate DoS by preventing the application from exacerbating network congestion.
    • Performance Degradation (Severity: Medium): Improves overall application performance and responsiveness under congested network conditions.

  • Impact:

    • DoS: Moderate risk reduction (indirect).
    • Performance Degradation: Significant improvement in performance and stability.

  • Currently Implemented:

    • Basic KCP congestion control is likely enabled by default, but the parameters might not be optimally tuned.

  • Missing Implementation:

    • Application-layer monitoring of KCP's performance metrics is likely missing.
    • The application-layer feedback loop (reducing the sending rate based on KCP's performance) is likely missing.
    • Fine-grained tuning of KCP's congestion control parameters (IKCP_WND_SND, IKCP_WND_RCV, ikcp_nodelay parameters) is likely not optimized.

Mitigation Strategy: Packet Size Limits (KCP Input)

  • Description:

    1. Maximum Segment Size (MSS) Awareness: Be aware of the Maximum Segment Size (MSS) configured in KCP (often indirectly through MTU settings).
    2. Input Validation: Within the ikcp_input function (or a wrapper immediately before it), check the size of the incoming data buffer.
    3. Rejection: If the size of the incoming data exceeds a predefined limit (which should be related to, but potentially smaller than, the MSS), discard the packet before any further processing by KCP.
    4. Logging: Log any discarded packets due to exceeding the size limit.

  • Threats Mitigated:

    • Denial of Service (DoS) (Severity: Medium): Prevents attackers from sending excessively large packets to consume resources within KCP.
    • Buffer Overflow Vulnerabilities (Severity: High): If a buffer overflow vulnerability exists within KCP's packet handling, this limit helps mitigate its exploitation.

  • Impact:

    • DoS: Moderate risk reduction.
    • Buffer Overflow: Significant risk reduction (if a vulnerability exists).

  • Currently Implemented:

    • Potentially handled implicitly by KCP's internal buffer management, but an explicit check is safer.

  • Missing Implementation:

    • Explicit size check and rejection before KCP's internal processing is recommended.
    • Logging of oversized packet discards.