Subject: [tcpm] big bunch o' icmp-attack comments

From: Mark Allman <[email-masked]>
Date: Tue, 30 May 2006 13:55:05 -0400

Folks-

(chair hat off)

Below are my comments on the icmp-attacks draft.  IMO, despite I don't
see this document as near ready yet.

allman

Meta:

  * The document is too prescriptive if indeed it is to be an
    informational type of document and not an update to the relevant
    specifications.

    As one egregious example (there are more), section 6 steps
    through that SQ messages are not supposed to be sent (RFC1812],
    but if received a host MUST react [RFC1122].  This supposed
    informational document then goes on to say: "Thus, hosts should
    completely ignore ICMP Source Quench messages meant for TCP
    connections."

    To me, this is a bogus avenue for an informational document to
    take.  I.e., if one takes only the text from 1122 and this
    document you'd surely assume this document was updating 1122
    with new thinking.  But, if one looks at the document class then
    you'd be left with being required to follow 1122 and react to SQ
    messages if you wanted to be compliant.  So, this sort of thing
    leaves us in a real mess, IMO.

    (There are other cases of this - e.g., the end of page 12
    effectively recommending against the "hard error" classification
    in RFC1122 in favor of a "soft error" treatment.)

    There are some SHOULDs in the previous documents and if this
    document wants to simply clarify or offer some suggested
    approaches within these SHOULDs then that's fine for an
    informational, I guess.  But, the document should be very clear
    when it is taking that approach.  And, for cases where these is
    no wiggle room in the current specifications we should not be
    trying to make some wiggle room.

    Note #1: I have zero heartburn with saying that hosts should
    ignore SQ messages.  My heartburn is with leaving things all
    ambiguous in the RFC series.

    Note #2: I cannot clearly reconstruct why the WG decided to head
    down the informational path at this point.  I would be happy to
    see that changed such that we can make these sorts of actual
    changes to the current specs.

    Note #3: Just because there are no capital letters doesn't mean
    the text doesn't come off as prescriptive.  I.e., the tone and
    the words themselves are as important in my eyes as whether one
    writes "must" or "MUST".

    Basically, I think I am agreeing with Joe and Bora here... as it
    stands if this document were an informational RFC I think it'd
    be a backdoor change to the previous specifications.  I think we
    need to think this through very carefully and craft appropriate
    text if we want to progress as an informational because the
    IESG, it would seem to me, would be well within the bounds of
    reasonableness to reject this sort of document for leaving
    things in an inconsistent and ambiguous state.

  * The analysis of the threat these attacks impose needs to be much
    more carefully laid out.  The current analysis is glib.  E.g.,
    in section 2.2 the text says: "If we assume the attacker knows
    the two end systems involved in the TCP connection to be
    attacked,".  Why would we assume that?  The argument continues
    that Internet services use well-known ports which leaves only
    one ephemeral port to be guessed.  But, first *which* well-known
    port is involved in the connection?  There are lots of them.
    The text seems to conclude that the worst case here is that you
    need to brute force 64K packets to get one wedged into the
    connection (which in general is very short, as well).  I think
    that is wildly overblown as a general argument.  You *might* be
    able to make this sort of case if you scope down to some case
    where it is actually plausible that you'd know some of this
    information (e.g., the BGP case).  But, this document is not at
    all careful about showing perspective as to when ICMP messages
    are an actual threat and when they are not.

  * I don't think the revised PMTUD algorithm is a fit for this
    document.  The revised algorithm may be perfectly fine (I would
    need to think on it more before I made up my mind one way or
    another).  But, the algorithm goes beyond the scope of simply
    fixing a security problem.  If this document wants to do only
    the security related stuff then that's fine.  But, I think the
    larger work ought to be split out and made into its own
    document.  We have a WG that is working on PMTUD and this would
    seem at first cut to be under their purview.

Section 1:

  * "While the security" --> "While the possible security"

Section 2.1:

  * "network congestion and rate-limiting" --> "network congestion
    or rate-limiting"

Section 2.1.1:

  * "report network errors" --> "report errors"

  * It's not clear to me why the middle two paragraphs are in here.
    Why are we calling attention to these two things specifically
    right here?

Section 3:

  * I am not an IPsec guru.  So, I don't understand a few things...

    (1) If I am using IPsec and get an ICMP back then how is that
        supposed to be processed.  In principle I *might* be able to
        match it to a connection because I saw the data go out on
        some connection and so I could still validate the first bits
        included in the reply.  Right?  I don't expect this happens
        because stacks don't hang onto packets they put on the wire
        to compare against, right?

    (2) So, are you hosed if you use IPsec?  That is, are your
        choices to either ignore them or to pass them to all
        connections between two addresses?  This draft argues
        against that sort of practice, but should it?  I.e., can't
        that lead to a PMTUD black hole or something?

    For an IPsec-idiot this document is sort of a mess.  I really
    don't know how this all plays together after reading the
    document.  (Note: I am not advocating re-writing other things,
    but a sketch and some references would be nice.)

Section 4.3:

  * I share the uneasiness expressed on the list with regards to
    this section.  It's usefulness seems low and at least needs
    better motivation.  One could put an extra warning in here that
    general egress filtering is useful and should be done.  E.g., so
    I don't forge an ICMP that is supposedly from Joe's machine.

Section 5.1:

  * "TCP is handled" --> "TCP is handed"

  * I didn't go back and look, but the notion of "frag needed" as a
    hard error seems odd to me.  I think the document could
    certainly clarify this a bit.  It's certainly not treated as a
    hard error.

  * More glibness about the ease of the attack: "even being
    off-path, an attacker could reset any TCP connection taking
    place".  Of course, I cannot prove this statement wrong.  But, I
    am willing to bet that in an empirical way it could not be shown
    to be accurate either.

Section 5.2.1:

  * It's not clear to me why you apply protocol unreachables to
    certain states and don't do the same thing to port unreachables.

Sections 6 & 7:

  * I don't quite understand the distinction between a
    "throughput-reduction" attack and a "performance-degradation"
    attack.  It seems like these two attacks should be subsections
    of the same section such that I don't have to think about
    whether there is a real reason for the distinction.

Section 7.1:

  * "(PMTUD) mechanism lets" --> "(PMTUD) lets"

  * "error message to sending" --> "error message to the sending"

  * You could cite the TCP model (Padhye 1998, Mathis 1997, etc.)
    which clearly shows the impact of packet size on performance.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm