Defending TCP Against Spoofing Attacks
Note: This ballot was opened for revision 06 and is now closed.
(Jari Arkko) Yes
Great document. Thanks for writing this. A few comments: > Under these > conditions, and further assuming that the initial sequence number is > suitably (pseudo-randomly) chosen, a valid guessed sequence number > would have odds of 1 in 57,000 of falling within the advertised > receive window. Put differently, a blind (i.e., off-path) attacker > would need to send 57,000 RSTs with suitably spaced sequence number > guesses to successfully reset a connection. I'm not sure this is accurate. Presumably 57,000/2 tries are needed on average. But are you trying to say that 57,000 tries guarantees a result? This may not follow, as the legitimate parties are also communicating and the window may move while the attack goes on. > Alternative mechanisms are under development to address this > limitation, to allow publicly-accessible servers to secure > connections to clients not known in advance, or to allow unilateral > relaxation of identity validation so that the remaining protections > of IPsec can be made available . In particular, these > mechanisms can prevent a client (but without knowing who that client > is) from being affected by spoofing from other clients, even when the > attackers are on the same communications path. Really? I looked at draft-ietf-btns-core-02 and it said BTNS is vulnerable to MITM attacks. This is probably fine for BTNS, but I am surprised to find the statement above that client spoofing is prevented even when the attackers are on the same communications path. Traditionally, zero-config security mechanisms have been able to prevent off-path attacks, but its hard to see how they could prevent on-path attacks if there is no CA to trust, no trusted DNS to get the HIT/key from, etc. >  Touch, J., "ANONsec: Anonymous Security to Defend Against > Spoofing Attacks", draft-touch-anonsec-00.txt (expired work in > progress), May 2004. Would draft-ietf-btns-core be a more recent reference to a solution?
(Ron Bonica) Yes
(Lars Eggert) Yes
Magnus Westerlund Yes
(Ross Callon) No Objection
(Russ Housley) No Objection
Gen-ART Review by Suresh Krishnan. Overall the draft is well written and has very comprehensive references of the problem and solution space (two thumbs up). Semi-substantial ================ * Page 20, this paragraph Alternative mechanisms are under development to address this limitation, to allow publicly-accessible servers to secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so that the remaining protections of IPsec can be made available . In particular, these mechanisms can prevent a client (but without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the same communications path. This paragraph claims that  and  can prevent on path attackers. From my reading of  and  I understood they were designed to prevent OFF-PATH attacks and not ON-PATH attacks. I do not know if they will protect against on-path attackers. Minor ===== * Figure 1 and Figure 2 have the same column names for 'BW*delay' but the numbers are not calculated in the same way. For figure 1 it is the bandwidth delay product, but for figure 2 it is the buffer size. So I feel it would be clearer if the column was labeled simply as "Receive Window Size". * I am not convinced about the following wording in Section 2.1 "Review of TCP Windows". Send window (SND.WND): the latest send window size. I might be wrong, but in my understanding the send window size is SND.WND only when there is no unacknowledged data. If there is any unacknowledged data the send window sized is reduced to SND.WND-(size of unacknowledged data).