Defending TCP Against Spoofing Attacks
draft-ietf-tcpm-tcp-antispoof-06
Yes
(Lars Eggert)
(Magnus Westerlund)
(Ron Bonica)
No Objection
(Chris Newman)
(Cullen Jennings)
(Mark Townsley)
(Ross Callon)
Note: This ballot was opened for revision 06 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
(2007-04-03)
Unknown
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 [45][46]. 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. > [45] 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?
Lars Eggert Former IESG member
Yes
Yes
()
Unknown
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-04-04)
Unknown
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 [45][46]. 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 [45] and [46] can prevent on path attackers.
From my reading of [45] and [46] 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).