Subject: [Softwires] Comments on draft-dec-stateless-4v6-02

From: Nejc Škoberne <[email-masked]>
Date: Mon, 22 Aug 2011 14:04:57 +0100

Dear authors,

I have some comments on section 5.9 Securty and Port Randomization.

-------------------------------------------------------------------
   Assuming all other information has already been acquired, and also
   the presence of no exploits, the basic security of IP protocols lies
   in the computational cost of guessing a combination of a protocol
   field, eg a TCP sequence number or say a DNS transaction ID,
   multiplied by a the cost of a guess of a source port.  Thus, for a
<snip>
   TCP brute force attack, the already substantial cost in guessing a
   sequence number (2^32 possibilities) is multiplied by the port range
   guess cost.  In this context a 1K port restricted 4V6 system, is
   costly enough for most practical purposes.  More discussion to
   improve the robustness of TCP against Blind In-Window Attacks can be
   found at [RFC5961].

[NS: The claim, that this is costly enough for most practical purposes,
is not true. This is also the motivation for RFC 5961, as I
understand it. The issue is, that it's not the 2^32 space we need to
search but rather 2^32/W, where W is the window size. And in practice,
W is 32-64k. Which is a huge reduction in complexity. If we know the 
source port, an attacker on a 100Mbit/s link can tear down a TCP session 
between another client and server (if server is at least 100Mbit/s as
well) in cca. 0.8 seconds (on average, see
RFC 5961 and "Slipping in the Window: TCP Reset attacks", Presentation
at 2004 CanSecWest). If we consider 10-bit port space (1024 ports per
customer), the average time increases to ~13.6 minutes, which is still
a very practicable attack for longer-lived-sessions. However, if we
have the whole 16-bit port range, the attack becomes considerably less
practicable (although still practicable with very long-lived sessions),
the average time is 14.5 hours. But that's an amount of time, where
other measures would possibly be triggered in case something strange
is going on.]

   For a UDP/DNS brute force attack, the computational cost required to
   scan/generate the full range of 2^32 possibilities, corresponding to
   a port unrestricted system is relatively low/easy - today's GPUs can
   do so in a few seconds.

[NS: I am not sure I understand the role of GPUs in sending guessing
packets?]

   Beyond the above, in terms of the avoiding a fixed linear or single
   port range allocations, extensions to the 4V6 solution provides
   additional remedy, eg [I-D.bajko-pripaddrassign].

[NS: I-D.bajko-pripaddrassign is expired and AFAIK it defines a DHCPv4
option to signal the port range/mask and a key to the client host/CPE.
I guess this is pretty useless in stateless solutions, where we don't
want to have such signaling. Also, you mention "4V6 solution". How do
you define this term?]
-------------------------------------------------------------------

Regards,
Nejc

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 23 Aug 2011 16:01:33 +0200

Nejc,

we indeed need some wordsmithing on that part of the text, but the message
that it tries to convey looks unaffected:

- If one believes that port unrestriced TCP provides "enough" security, then
the port-restriction does little to alter that in consideration of host/CPE
practices (no randomization). As you point out, such "belief" may be
misplaced, especially with larger widow sizes. Granted, a system with full
random source port selection across the full port range is ideal.
- The security offered by UDP is easily overcome with very modest resources.
The CPU/GPU reference is made to illustrate the point that computationally
it is trivial, and it's worth adding that bandwidth wise it is also likely
to be so esp on a high speed link.

The paper you indicated provides a neat summary of the level of security
based on source ports as offered by many implementations still today,
including those of CPEs:

---snip---

Moreover, ephemeral source ports are not actually selected from the full
16-bit range, but a smaller subset range.  Ports 1-1024 are reserved for
privileged processes, and ports 49152-65535 are reserved for private ports.
In some cases, operating systems have even reserved ports 5001-65535 for
private usage, leaving only 3977 ports for dynamic kernel assignment.
Currently, existing source port selection is so predictable as to make
guessing reasonably trivial; even for the blind TCP spoofing attacker.

---snip---

Regards,
Woj.

2011/8/22 Nejc Škoberne <[email-masked]>

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Nejc Škoberne <[email-masked]>
Date: Tue, 23 Aug 2011 16:06:40 +0100

Dear Wojciech,

> - If one believes that port unrestriced TCP provides "enough" security, 
> then the port-restriction does little to alter that in consideration of 
> host/CPE practices (no randomization). As you point out, such "belief" 
> may be misplaced, especially with larger widow sizes. Granted, a system 
> with full random source port selection across the full port range is ideal.

My point was, that this "little" is not as little as some people might
think. This is what I tried to show with my calculation. I still think
the difference is significant in practice and that using port-restricted
systems without any measures (like random port selection in
draft-bajko-pripaddrassign-03) is one of the trade-offs which should be
considered when deciding on a mechanism. That's all.

> - The security offered by UDP is easily overcome with very modest 
> resources. The CPU/GPU reference is made to illustrate the point that 
> computationally it is trivial, and it's worth adding that bandwidth wise 
> it is also likely to be so esp on a high speed link.

But what do you have to compute anyway? It's just trying 2^32 values
until you get "a bingo". So I don't think it is the computational 
complexity which is relevant here, but rather bandwidth or preferrably
packet rate. That's why I would just remove the GPU part.

> 16-bit range, but a smaller subset range.Ports 1-1024 are reserved for 
> privileged processes, and ports 49152-65535 are reserved for private 
> ports.In some cases, operating systems have even reserved ports 
> 5001-65535 for private usage, leaving only 3977 ports for dynamic kernel 
> assignment.
> 

Indeed. But I think have to consider long-term consequences? I can
imagine that operating systems will start to implement RFC 6056 eventually
and when they do, it will be these NAT-based port-restricted mechanisms,
which will degrade security (of course, only to certain extent). And
people should be aware of this.

Thanks,
Nejc