Defending TCP Against Spoofing Attacks
RFC 4953

Note: This ballot was opened for revision 06 and is now closed.

(Jari Arkko) Yes

Comment (2007-04-03)
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?

(Ron Bonica) Yes

(Lars Eggert) Yes

(Magnus Westerlund) Yes

(Ross Callon) No Objection

(Russ Housley) No Objection

Comment (2007-04-04)
  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).

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Mark Townsley) No Objection