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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
