[tcpm] Alfred Hoenes: draft-ietf-tcpm-icmp-attacks-01 (etc.)

[Fernando Gont <[e-mail]>]

Folks,

I received this feedback from Alfred Hoenes. I will most my answers soon.


>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[e-mail]>
>Subject: draft-ietf-tcpm-icmp-attacks-01 (etc.)
>To: [e-mail]
>Date: Wed, 10 Jan 2007 01:10:02 +0100 (MEZ)
>
>Hello,
>after studying your I-D, draft-ietf-tcpm-icmp-attacks-01,
>I would like to send you e few comments pointing out (mostly)
>textual issues I found in that draft (and in a related note
>you have posted).
>
>After reading your exposition, I really wonder why these issues,
>and the countermeasures against, have not been discovered already
>many years ago -- such clear is the threat, und such logical seem
>the remedies!
>
>Here are the textual issues I found in the draft, documented as:
>
>    <original text>
>---
>    <proposed/changed text>
>
>I use change bars ('|' in column 1) and occasionally
>up/down pointing marker lines ('^^^'/'vvv') to emphasize
>the location of textual issues and/or proposed corrections.
>All snippits are taken preserving the original identation
>and formatting; modified text has been re-adjusted to match
>I-D / RFC formatting rules, where appropriate.
>
>
>(1)  Section 1:
>
>In the first paragraph:
>
>    ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
>    and is used mainly for reporting network error conditions.  However,
>    the current specifications do not recommend any kind of validation
>|  checks on the received ICMP error messages, thus allowing variety of
>    attacks against TCP [RFC0793] by means of ICMP, which include blind
>    connection-reset, blind throughput-reduction, and blind performance-
>    degrading attacks.  All of these attacks can be performed even being
>    off-path, without the need to sniff the packets that correspond to
>    the attacked TCP connection.
>---
>    ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
>    and is used mainly for reporting network error conditions.  However,
>    the current specifications do not recommend any kind of validation
>|  checks on the received ICMP error messages, thus allowing a variety
>    of attacks against TCP [RFC0793] by means of ICMP, which include
>    blind connection-reset, blind throughput-reduction, and blind
>    performance-degrading attacks.  All of these attacks can be performed
>    even being off-path, without the need to sniff the packets that
>    correspond to the attacked TCP connection.
>
>(2)  Section 2.2
>
>(2a)
>In the 4th paragraph, there's the first occurrence of an 'unsatisfied'
>reference tag (see marked line below):   [Touch-antispoof]
>This same tag recurs in the last sentence of Section 4.1, but it does
>*not* appear in the References sections.
>
>I guess (after browsing the I-D index) that it should be:
>             draft-ietf-tcpm-tcp-antispoof-05
>
>Please add the appropriate bibliographic entry to Section 10.2
>
>(2b)
>In the same paragraph, there's a typo (singular/plural mismatch):
>
>    Generally, the four-tuple required to perform these attacks is not
>|  known.  However, as discussed in [Watson] and [Touch-antispoof],
>    there are a number of scenarios (notably that of TCP connections
>    established between two BGP routers), in which an attacker may be
>    able to know or guess the four-tuple that identifies a TCP
>    connection.  In such a case, if we assume the attacker knows the two
>    systems involved in the TCP connection to be attacked, both the
>    client-side and the server-side IP addresses could be known or be
>    within a reasonable number of possibilities.  Furthermore, as most
>    Internet services use the so-called "well-known" ports, only the
>|  client port number might need to be guessed.  In such a scenario, an
>    attacker would need to send, in principle, at most 65536 packets to
>    perform any of the attacks described in this document.  However, as
>    most systems choose the port numbers they use for outgoing
>    connections from a subset of the whole port number space, the amount
>    of packets needed to successfully perform any of the attacks
>    discussed in this document could be further reduced.
>---
>    Generally, the four-tuple required to perform these attacks is not
>    known.  However, as discussed in [Watson] and [Touch-antispoof],
>    there are a number of scenarios (notably that of TCP connections
>    established between two BGP routers), in which an attacker may be
>    able to know or guess the four-tuple that identifies a TCP
>    connection.  In such a case, if we assume the attacker knows the two
>    systems involved in the TCP connection to be attacked, both the
>    client-side and the server-side IP addresses could be known or be
>    within a reasonable number of possibilities.  Furthermore, as most
>    Internet services use the so-called "well-known" ports, only the
>|  client port number might needs to be guessed.  In such a scenario, an
>    attacker would need to send, in principle, at most 65536 packets to
>    perform any of the attacks described in this document.  However, as
>    most systems choose the port numbers they use for outgoing
>    connections from a subset of the whole port number space, the amount
>    of packets needed to successfully perform any of the attacks
>    discussed in this document could be further reduced.
>
>(3)  Section 2.3
>
>In the first paragraph, there's a typo (missing "of"), and a sentence
>with two verbs.  I guess the "receives" should be deleted in favour of
>the "is":
>
>|  Section 5.2 of [RFC4301] describes the processing inbound IP Traffic
>    in the case of "unprotected-to-protected".  In the case of ICMP, when
>    an unprotected ICMP error message is received, it is matched to the
>    corresponding security association by means of the SPI (Security
>    Parameters Index) included in the payload of the ICMP error message.
>    Then, local policy is applied to determine whether to accept or
>    reject the message and, if accepted, what action to take as a result.
>    For example, if an ICMP unreachable message is received, the
>    implementation must decide whether to act on it, reject it, or act on
>    it with constraints.  Section 8 ("Path MTU/DF processing") discusses
>    the processing of unauthenticated ICMP "fragmentation needed and DF
>    bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" (type 2, code
>|  0) messages when an IPsec implementation receives is configured to
>    process (vs. ignore) such messages.
>---
>|  Section 5.2 of [RFC4301] describes the processing of inbound IP
>    Traffic in the case of "unprotected-to-protected".  In the case of
>    ICMP, when an unprotected ICMP error message is received, it is
>    matched to the corresponding security association by means of the SPI
>    (Security Parameters Index) included in the payload of the ICMP error
>    message.  Then, local policy is applied to determine whether to
>    accept or reject the message and, if accepted, what action to take as
>    a result.  For example, if an ICMP unreachable message is received,
>    the implementation must decide whether to act on it, reject it, or
>    act on it with constraints.  Section 8 ("Path MTU/DF processing")
>    discusses the processing of unauthenticated ICMP "fragmentation
>    needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big"
>|  (type 2, code 0) messages when an IPsec implementation is configured
>    to process (vs. ignore) such messages.
>
>(4)  Section 5.2
>
>I did not understand the last sentence in that (single) paragraph
>there, until I finally arrived at guesssing that the word "advice"
>perhaps should be deleted.
>
>                                                        [...].  Given the
>    hostile environments in which TCP currently operates in, and that
>|  advice ICMP provides an attack vector that is easier to exploit than
>    others (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we
>    believe that the improvements in TCP's resistance to these attacks
>    justify not taking the advice provided by the "SHOULDs" in [RFC1122].
>---
>                                                        [...].  Given the
>    hostile environments in which TCP currently operates in, and that
>|  ICMP provides an attack vector that is easier to exploit than others
>    (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we believe
>    that the improvements in TCP's resistance to these attacks justify
>    not taking the advice provided by the "SHOULDs" in [RFC1122].
>
>(5)  Section 5.2.1
>
>(5a)
>In the first paragraph, the wording should be improved:
>
>    An analysis of the circumstances in which ICMP messages that indicate
>|  hard errors may be received can shed some light to eliminate the
>    impact of ICMP-based blind connection-reset attacks.
>---
>    An analysis of the circumstances in which ICMP messages that indicate
>|  hard errors may be received can shed some light on how to eliminate
>    the impact of ICMP-based blind connection-reset attacks.
>
>(5b)
>In the discussion of the
>
>    ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
>    destination administratively prohibited)
>
>there is a sentence that did not make sense to me; maybe it does not
>even say what you wanted to say :
>
>                    [...]  However, there is no reason to think that in
>       the same way this error condition appeared, it will not get solved
>       in the near term.  [...]
>
>I guess it was intended to state something like:
>
>                           In real life, this error condition will appear
>       very rarely; if it persists, it will be handled correctly after the
>       ensuing ACK timeout.
>
>(5b)
>In the paragraph after the five ICMP message type explanations (this is
>the 5th-to-last paragraph of the section), there are two sentences with
>two verbs each: "is" + "is" , and "are" + "indicate" , respectively:
>
>    Therefore, when following the reasoning explained above, TCPs in
>    synchronized states would treat all of the above messages as
>    indicating "soft errors", rather than "hard errors", and thus would
>|  not abort the corresponding connection upon receipt of them.  This is
>    policy is based on the premise that TCP should be as robust as
>    possible.  Reaction to these messages when they are meant for
>    connections in non-synchronized states could still remain as adviced
>    by [RFC1122], as we consider the attack window for connections in the
>    non-synchronized states is very small, and error messages received in
>|  these states are more likely indicate that the connection was opened
>    improperly [RFC0816].  Additionally, for the sake of robustness and
>    security, those implementations following the reasoning explained in
>    this section would not extrapolate ICMP errors across TCP
>    connections.
>---
>    Therefore, when following the reasoning explained above, TCPs in
>    synchronized states would treat all of the above messages as
>    indicating "soft errors", rather than "hard errors", and thus would
>|  not abort the corresponding connection upon receipt of them.  This
>    policy is based on the premise that TCP should be as robust as
>    possible.  Reaction to these messages when they are meant for
>    connections in non-synchronized states could still remain as adviced
>    by [RFC1122], as we consider the attack window for connections in the
>    non-synchronized states is very small, and error messages received in
>|  these states more likely indicate that the connection was opened
>    improperly [RFC0816].  Additionally, for the sake of robustness and
>    security, those implementations following the reasoning explained in
>    this section would not extrapolate ICMP errors across TCP
>    connections.
>
>(5c)
>In the subsequent paragraph, the above 'magic' sentence recurs in
>slightly modified form:
>
>    In case the received message were legitimate, it would mean that the
>    error condition appeared during the life of the corresponding
>|  connection.  However, in many scenarios there is no reason to think
>|  that in the same way this error condition appeared, it will not get
>|  solved in the near term.  [...]
>
>"there is no reason to think that ... it will not get solved ..."
>just contains too many negations.  This sentence might be replaced
>in a similar way as proposed above.
>
>(5d)
>Stepping ahead, in the next paragraph (3rd-to-last in the Section),
>the wording should preferrably be improved:
>
>|  One scenario in which a host would benefit from treating the so-
>    called ICMP "hard errors" as "soft errors" would be that in which the
>    packets that correspond to a given TCP connection are routed along
>    multiple different paths.  [...]
>---
>|  Another scenario in which a host would benefit from treating the so-
>    called ICMP "hard errors" as "soft errors" would be that in which the
>    packets that correspond to a given TCP connection are routed along
>    multiple different paths.  [...]
>
>(5e)
>The next paragraph deals with ignored error messages and out-of-band
>signalling of error conditions.  Therefore, "received error messages"
>should better be replaced by just "error conditions" :
>
>    It is interesting to note that, as ICMP error messages are
>    unreliable, transport protocols should not depend on them for correct
>    functioning.  In the event one of these messages were legitimate, the
>    corresponding connection would eventually time out.  Also,
>|  applications may still be notified asynchronously about the received
>|  error messages, and thus may still abort their connections on their
>    own if they consider it appropriate.
>---
>    It is interesting to note that, as ICMP error messages are
>    unreliable, transport protocols should not depend on them for correct
>    functioning.  In the event one of these messages were legitimate, the
>    corresponding connection would eventually time out.  Also,
>|  applications may still be notified asynchronously about the error
>|  conditions, and thus may still abort their connections on their own
>    if they consider it appropriate.
>
>[ In place of "error conditions", you might prefer "error condition",
>   "errors", or "error" . ]
>
>(6)  Section 5.2.3
>
>(6a)
>As in (5e) above (including the note), in the first paragraph:
>
>                 [...].  It should also be noted that applications may
>|  still be notified asynchronously about the received error messages,
>    and thus may still abort their connections on their own if they
>    consider it appropriate.
>---
>                 [...].  It should also be noted that applications may
>|  still be notified asynchronously about the error conditions, and thus
>    may still abort their connections on their own if they consider it
>    appropriate.
>
>(6b)
>And again, in the second paragraph:
>
>        [...].  Additionally, applications may still be notified
>|  asynchronously about the received error messages, and thus may still
>    abort their connections on their own if they consider it appropriate.
>---
>        [...].  Additionally, applications may still be notified
>|  asynchronously about the error conditions, and thus may still
>    abort their connections on their own if they consider it appropriate.
>
>(7)  Section 6.1
>
>At the end of the (single) paragraph, add the missing article, "an":
>
>|              [...].  The throughput achieved during attack might be a
>    little higher if a larger initial congestion window is in use
>    [RFC3390].
>---
>|              [...].  The throughput achieved during an attack might be
>    a little higher if a larger initial congestion window is in use
>    [RFC3390].
>
>(8)  Section 7.1
>
>I propose a textual enhancement in the 5th paragraph.
>IMHO, the referred to "IRQ ... rate" problem is only one face of the
>whole story.  Below, I substitute "protocol processing time" for that
>(you might also add it, as "IRQ ... rate and protocol processing time").
>
>                                                        [...].  On
>|  virtually all systems this will lead to an increase in the IRQ
>|  (Interrrupt ReQuest) rate, thus increasing processor utilization, and
>    degrading the overall system performance.
>---
>                                                        [...].  On
>|  virtually all systems this will lead to an increase in the protocol
>|  processing time, thus increasing processor utilization, and degrading
>    the overall system performance.
>
>(9)  Section 7.2
>
>(9a)
>In the classification performed:
>
>    To achieve both goals, we can divide the traditional PMTUD mechanism
>    into two stages: Initial Path-MTU Discovery, and Path-MTU Update.
>
>the latter apparently is intended to deal with PMTU reduction only,
>as can be seen from the subsequent discussion.
>
>IMHO, that has one serious drawback: it does not cover the "probing
>for PMTU increase" described in the third paragraph of Section 3 of
>RFC 1191, intended to discover effective PMTU introduced by routing
>changes.  I'm not sure whether this procedure is handled gracefully
>by your algorithm -- but I might err here; I just do not have enough
>spare time to delve into performing 'mental simulation' for that
>scenario now.  Please check.
>
>In any case, I would appreciate an extended discussion clearly
>covering this third case, throughout Section 7.2, and perhaps also
>an addition to Appendix A showing the behaviour during PMTU probing.
>
>(9b)
>In the 17th paragraph of Section 7.2, perhaps "everytime" should be
>replaced by "every time", according to the context.
>
>(10)  References
>
>(10a)  missing entry -- see (2a) above
>
>(10b)
>There's a typo in your own URI  [Ouch!] :
>
>    [ICMP-Filtering]
>               Gont, F., "Filtering of ICMP error messages",  http://
>               www.gont.com.ar/papers/filtering-icmp-error-messages.pdf.
>---
>    [ICMP-Filtering]
>               Gont, F., "Filtering of ICMP error messages",  http://
>               www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf.
>                                               ^^^
>BTW:
>... And in that memo, I found two small typos as well:
>
>(F1)  First bullet on page 1:
>       "on of"  -->  "one of"
>
>(F2)  First subordinate bullet of first bullet on page 2:
>       "intermmediate"  -->  "intermediate"
>
>(11)  Appendix B
>
>(11a)
>Repeated "far" <--> "for" ; missing punctuation
>
>    maxsizeacked
>       Variable holding the largest packet size (data, plus headers) that
>|     has so for been acked far this connection, as explained in
>|     Section 7.2
>---
>    maxsizeacked
>       Variable holding the largest packet size (data, plus headers) that
>|     has so far been acked for this connection, as explained in
>|     Section 7.2.
>
>    maxsizesent
>       Variable holding the largest packet size (data, plus headers) that
>|     has so for been sent far this connection, as explained in
>|     Section 7.2
>---
>    maxsizesent
>       Variable holding the largest packet size (data, plus headers) that
>|     has so far been sent for this connection, as explained in
>|     Section 7.2.
>
>    nsegrto
>       Variable holding the number of times this segment has timed out,
>|     as explained in Section 7.2
>---
>    nsegrto
>       Variable holding the number of times this segment has timed out,
>|     as explained in Section 7.2.
>
>    packet_size
>|     Variable holding the size of the IP datagram being sent
>---
>    packet_size
>|     Variable holding the size of the IP datagram being sent.
>
>(11b)
>In the pseudocode for
>
>    EVENT: Segment is received
>
>correct
>         if (pending_mesage)
>---
>         if (pending_message)
>
>(11c)
>The presentation of the pseudocode for
>
>    EVENT: ICMP "Packet Too Big" message is received
>
>suffers from the deep nesting and varying use of braces.
>[Note: That's perfectly o.k. from a syntax point of view (in 'C').]
>I propose to streamline the presentation to enhance the readability,
>by making it more compact and better show the structure of a single
>case switch (exactly one of the code blocks is to be executed in
>any case):
>
>         if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT){
>              drop_message();
>|       }
>|
>|       else {
>|            if (claimedmtu >= maxsizesent || claimedmtu >= current_mtu)
>                   drop_message();
>|
>|            else {
>|                 if (claimedmtu > maxsizeacked){
>                        adjust_mtu();
>                        current_mtu = claimedmtu;
>                        maxsizesent = MINIMUM_MTU;
>|                 }
>|
>|                 else {
>                        pending_message = 1;
>                        save_message();
>|                 }
>|            }
>         }
>---
>|       if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >= SND.NXT) {
>|           drop_message();
>|       } else if (claimedmtu >= maxsizesent ||
>|                  claimedmtu >= current_mtu) {
>|           drop_message();
>|       } else if (claimedmtu > maxsizeacked) {
>|           adjust_mtu();
>|           current_mtu = claimedmtu;
>|           maxsizesent = MINIMUM_MTU;
>|       } else {
>|           pending_message = 1;
>|           save_message();
>|       }
>
>[ This time, I also have tagged the lines that only had their
>   indentation changed, because that's the visual clue intended; I have
>   removed the redundant braces of type   else { if <statement> } ,
>   but added (arguably redundant) braces around the second instance of
>   drop_message();  just for symmetry;  the line break after '||' is
>   introduced only to accomodate for the line length restriction. ]
>
>(12)  Appendix E
>
>(12a)
>Apparently there is something wrong with E.1 and E.2 :
>
>E.1.  Changes from draft-gont-tcpm-icmp-attacks-05       <---+
>E.2.  Changes from draft-ietf-tcpm-icmp-attacks-00       <---+
>E.3.  Changes from draft-gont-tcpm-icmp-attacks-04
>E.4.  Changes from draft-gont-tcpm-icmp-attacks-03
>E.5.  Changes from draft-gont-tcpm-icmp-attacks-02
>E.6.  Changes from draft-gont-tcpm-icmp-attacks-01
>E.7.  Changes from draft-gont-tcpm-icmp-attacks-00
>
>Shouldn't the sequence of the subsections correspond to the history,
>with the  draft-ietf-*-00  being the latest, listed first?
>
>I do not know whether just the headlines are exchanged, or the full
>sub-sections are misoredered.  Please check.
>
>(12b)  typo in current E.2 :
>
>|  o  Added an specific section on IPsec (Section 2.3)
>---
>|  o  Added a specific section on IPsec (Section 2.3)
>
>(12b)  garbage in E.6 :
>
>|  o  Added Section on Acknowledgement number checking"/>
>---
>|  o  Added Section on Acknowledgement number checking
>
>
>Best regards,
>   Alfred HÎnes.
>
>--
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
>| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
>| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
>+------------------------+--------------------------------------------+

--
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






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