Defending TCP Against Spoofing Attacks
draft-ietf-tcpm-tcp-antispoof-06

[Ballot comment]
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).

[Ballot comment]
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?

Document Shepherd Write-Up

1 a.
Ted Faber
1 b.
The document has had adequate review
1 c.
The document has had adequate review
1 d.
I don't believe that there are outstanding issues regarding the
acceptability of teh document to the WG or any spoilers to be
found in advancing it.

1 e.
WG consensus seems to be solid.  There were 2 WGLCs, one of
which raised substantive unaddressed issues.  Those issues were
addressed and the second WGLC completed with those problems
resolved to the satisfaction of those involved and the WG.

1 f.
No extreme discontent.  Pekka Savola expresses concerns that he
said he would raise at an IETF last call at one point, but I
believe those concerns have been addressed during WGLC.  Pekka's
concerns centered on the effectiveness of ingress filtering on
addressing the problems with spoofing.

1 g.
I've done the check.
The only issue is that two referenced drafts have had their
version numbers bumped since this version was handed to us.
They are:
draft-ietf-tcpm-syn-flood-01
draft-ietf-tcpm-tcpsecure-06

1 h.
No normative refs.  Informational RFC.
1 i.
No substantive IANA section.  Informational RFC.
1 j.
No such sections.
1 k.

Technical Summary

This document is a description fo the sorts of off-path spoofing
attacks that TCP is vulnerable to and the various existing ane
proposed mitigations of those attacks.  It is a fairly detailed
discussion of the attacks and forms a good basis for sddressing
the problems in TCP as well as starting the discussion for other
protocols.  More practically, it can be used by designers and
implementors to decide which of these strategies are appropriate
for their situation.

Working Group Summary

The draft came in to being primarily becayse the author was
concerned that a new draft addressing these vulnerabilities did
not adeqyately address prior work or present alternatives to
that draft's solutions.  Eventaully those concerns were
separated into this draft, which the group believes has
pedagogical and practical value.

Document Quality

The document has been endorsed by the working group as being
complete and well written pretty universally.

Personnel
Document Shepherd: Ted Faber
Responsible AD: Lars Eggert