Subject: [tcpm] FW: draft-ietf-tcpm-tcpsecure-06

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Thu, 15 Feb 2007 08:49:20 -0800

I am sending the comments which we received from Alfred to the wider audience. I have gone through that and most of them look acceptable. Revision 07 which will posted very soon would incoporate these comments among other things. I'll also broadcast the response which is being sent to Alfred.

Thanks,
-Anantha

-----Original Message-----
From: Alfred HÎnes [mailto:[email-masked]] 
Sent: Wednesday, January 17, 2007 10:22 AM
To: Anantha Ramaiah (ananth); Randall Stewart (rrs); Mitesh Dalal (mdalal)
Subject: draft-ietf-tcpm-tcpsecure-06

Hello,
after studying the Internet-Draft authored/edited by you,
    draft-ietf-tcpm-tcpsecure-06,
I'd like to submit a few comments, addressing the many textual/editorial flaws I found in that memo.

The items below are presented in textual order.
To give more context, sometimes I quote larger blocks of text literally and show the proposed replacement in the shorthand
notation:

   <original draft text>
---
   <modified 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.
Modified text has been re-adjusted to match RFC formatting rules, where appropriate.  I also try to accomodate published RFC-Ed policy on style and punctuation etc. in my porposals.

(0)  obsolete Ref.

[RFC1771] has been obsoleted, one year ago, by RFC 4271, January 2006.

Please update the multiple references.  Below, I only include the appropriate changes for snippits presented for other reasons as well.

(1)  Abstract, end of 1st paragraph

                                            [...].  A combination of
|  increasing window sizes and applications using a longer term  
| connections (e.g.  H-323 or Border Gateway Protocol [RFC1771]) have
   left modern TCP implementation more vulnerable to these types of
   spoofed packet injection attacks.
---
                                            [...].  A combination of
|  increasing window sizes and applications using longer term  
| connections (e.g., H-323 or Border Gateway Protocol [RFC1771]) have
   left modern TCP implementation more vulnerable to these types of
   spoofed packet injection attacks.

(2)  Section 1, 1st paragraph

   TCP [RFC0793] is widely deployed and the most common reliable end to
   end transport protocol used for data communication in todays
   Internet.  Yet when it was defined over 20 years ago the Internet, as
   we know it, was a different place lacking many of the threats that
   are now common.  TCP spoofing attacks are one such attack that are
   seen on the Internet today.
---
   TCP [RFC0793] is widely deployed and the most common reliable end to
|  end transport protocol used for data communication in today's  
| Internet.  Yet when it was defined over 30 years ago, the Internet,  
| as we know it, was a different place, lacking many of the threats
   that are now common.  TCP spoofing attacks are one such attack that
   are seen on the Internet today.

[Note: The first TCP Specification published as an RFC was RFC 675,  December 1974, obsoleted by RFC 761 (January 1980), and finally  RFC 793 = STD 7 (September 1981).  According to Jon Postel, there  have been at 7 earlier editions of the TCP specification not  circulated as RFCs.
 So don't tell a ripe, 32+ years ol' TCP a teenager ! ]

(3)  Section 1.1 

In bullet 1):

      ... number of factors most notably ...
---
      ... number of factors, most notably ...
                           ^
In the last paragraph:

      ... much more difficult then ...
---
      ... much more difficult than ...
                                ^

(4)  Section 1.2

Typos in the 5th paragraph:

   For the purposes of the rest of this discussion we will assume that
   the attacker knows the 4-tuple values.  This assumption will help us
|  focus on the effects of the window size verses the number of TCP
   packets an attacker must generate.  This assumption will rarely be
   true in the real Internet since at least the client port number will
   provide us with some amount of randomness (depending on operating
   system).
---
   For the purposes of the rest of this discussion we will assume that
   the attacker knows the 4-tuple values.  This assumption will help us
|  focus on the effects of the window size versus the number of TCP
   packets an attacker must generate.  This assumption will rarely be
   true in the real Internet since at least the client port number will
|  provide us with some amount of randomness (depending on the operating
   system).

In the 6th paragraph, I recommend to replace the uppercase 'X' by a lowercase 'x' as a multiplication sign, or use '*' instead.
Simplification by evaluation of the [constant parts of the] terms ("constant folding") might be considered as well.

At the end of the 8th paragraph:

       [...].  Resetting the connection can result in medium term
   unavailability due to the need to rebuild routing tables and route
   flapping see [NISCC] for further details.
---
       [...].  Resetting the connection can result in medium term
   unavailability due to the need to rebuild routing tables and route
|  flapping; see [NISCC] for further details.
           ^
9th paragraph:

   It also needs to be emphasized that for applications like BGP which
   use the TCP MD5 option [RFC2385], can make the attacks described in
   this specification much harder to accomplish.
---
|  It also needs to be emphasized that, for applications like BGP, use  
| of the TCP MD5 option [RFC2385] can make the attacks described in
   this specification much harder to accomplish.
or:
|  It also needs to be emphasized that for applications like BGP using  
| the TCP MD5 option [RFC2385], the attacks described in this  
| specification are much harder to accomplish.

10th (= last) paragraph:
                           vvvvvvvvvv                              vv?
|  It should be noted that there are existing alternative protection
   against the threats that this document addresses.  [...]
---                                                                 v
|  It should be noted that there are existing alternative protections
   against the threats that this document addresses.  [...]

(5)  Section 3.2 -- multiple typos

Below bullet '2)' :

   Instead, this document requires that implementations MUST perform the
   following steps in place of those specified in [RFC0793](listed
   above).
---                                                       ^^
   Instead, this document requires that implementations MUST perform the
|  following steps in place of those specified in [RFC0793] (as listed
   above).
                                                           ^^^^^ [ For additional clarification, I have added the word "as". ]

In bullet 'C)'

      The previous text,quoted from [RFC0793] ...
---
      The previous text, quoted from [RFC0793] ...
                        ^
and subsequently:
                                    vvvvvvv
|                        [...].  If the the RST arrives and its sequence
      number field does NOT match the next expected sequence number but
      is within the window, then the receiver should generate an ACK.
---
|                        [...].  If the RST arrives and its sequence
      number field does NOT match the next expected sequence number but
      is within the window, then the receiver should generate an ACK.

and finally, at the end of the bullet:

                                          [...].  This second RST if it
      reaches the sender will cause the connection to be aborted since
      the sequence number would now be an exact match.
---
|                                         [...].  This second RST, if it
|     reaches the sender, will cause the connection to be aborted since
      the sequence number would now be an exact match.
or:
|                                         [...].  If this second RST
|     reaches the sender, it will cause the connection to be aborted
      since the sequence number would now be an exact match.

And at the end of the section, add the missing full stop :

      [...].  This concern is discussed in Section 9.
                                                    ^

(6)  Section 4.1
  vv                                             v
   Analysis of the reset attack using the RST bit, highlights another
   possible avenue for a blind attacker using a similar set of sequence
   number guessing.  [...]
---
|  The Analysis of the reset attack using the RST bit highlights another
   possible avenue for a blind attacker using a similar set of sequence
   number guessing.  [...]

(7)  Section 4.2

In the 2nd paragraph after bullet 'A)' :

                     [...].  Upon receipt of a valid RST, the local TCP
|  endpoint MUST terminate its connection.  The local TCP endpoint
   should then rely on SYN retransmission from the remote end to re-
   establish the connection.
---
                     [...].  Upon receipt of a valid RST, the local TCP
|  endpoint MUST terminates its connection.  The local TCP endpoint
   should then rely on SYN retransmission from the remote end to re-
   establish the connection.

In the 4th paragraph after bullet 'A)' , change  "non spoofed SYN"  -->  "non-spoofed SYN" .

And at the end of the section, add the missing full stop :

      [...].  This concern is discussed in Section 9.
                                                    ^

(8)  Section 5.1

Typos and mismatched parentheses in the 1st paragraph:

   A third type of attack is also highlighted by both the RST and SYN
   attacks.  It is also possible to inject data into a TCP connection by
|  simply guessing the a sequence number within the current receive
   window of the victim.  The ACK value of any data segment is
   considered valid as long as it does not acknowledge data ahead of the
   next segment to send.  In other words an ACK value is acceptable if
|  it is (SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT).  This means that an
   attacker has to guess two ACK values with every guessed sequence
|  number so that the chances successfully injecting data into a
   connection are 1 in ((2^32 / RCV.WND) * 2).
---
   A third type of attack is also highlighted by both the RST and SYN
   attacks.  It is also possible to inject data into a TCP connection by
|  simply guessing a sequence number within the current receive window
   of the victim.  The ACK value of any data segment is considered valid
   as long as it does not acknowledge data ahead of the next segment to
   send.  In other words an ACK value is acceptable if it is
|  ((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT).  This means that an
   attacker has to guess two ACK values with every guessed sequence
|  number so that the chances of successfully injecting data into a
   connection are 1 in ((2^32 / RCV.WND) * 2).

(9)  Section 5.2

Typos, and improved wording, in the 1st paragraph:

   An additional input check MUST be added to any incoming segment.  The
   ACK value MUST be acceptable only if it is in the range of ((SND.UNA
|  - MAX.SND.WND) <= SEG.ACK <= SND.NXT).A new state variable
   MAX.SND.WND is defined as the largest window that the local sender
|  has ever received from its peer.  This window may be a scaled value  
| i.e. the value may be larger than 65,535 bytes ([RFC1323]).  This
   small check will reduce the vulnerability to an attacker guessing a
   valid sequence number since not only must he/she guess the sequence
   number in window, but must also guess a proper ACK value within a
   scoped range.  This mitigation reduces but does not eliminate the
   ability to generate false segments.  It does however reduce the
   probability that invalid data will be injected.
---
   An additional input check MUST be added to any incoming segment.  The
   ACK value MUST be acceptable only if it is in the range of ((SND.UNA
|  - MAX.SND.WND) <= SEG.ACK <= SND.NXT).  A new state variable
   MAX.SND.WND is defined as the largest window that the local sender
|  has ever received from its peer.  This window may be scaled to a  
| value larger than 65,535 bytes ([RFC1323]).  This small check will
   reduce the vulnerability to an attacker guessing a valid sequence
|  number, since he/she not only must guess the in-window sequence  
| number, but also a proper ACK value within a scoped range.  This  
| mitigation reduces, but does not eliminate, the ability to generate
   false segments.  It does, however, reduce the probability that
   invalid data will be injected.

And again, at the end of the section, add the missing full stop :

      [...].  This concern is discussed in Section 9.
                                                    ^

(10)  Section 6

2nd paragraph after the numbered bullets:
                                    vvv
|  An implementation SHOULD include a ACK throttling mechanism to be
   conservative.  [...]
---                                 vvvv
|  An implementation SHOULD include an ACK throttling mechanism to be
   conservative.  [...]

(11)  Section 8.1

1st paragraph:

   Consider a middlebox M-B tracking connection between two TCP endhosts
   E-A and E-C.  If E-C sends a RST with a sequence number that is
   within the window but not an exact match to reset the connection and
   M-B does not have the fix recommended in this document, it may clear
   the connection and forward the RST to E-A saving an incorrect
   sequence number.  [...]
---                                            v
|  Consider a middlebox M-B tracking connections between two TCP
   endhosts E-A and E-C.  If E-C sends a RST with a sequence number that
   is within the window but not an exact match to reset the connection
   and M-B does not have the fix recommended in this document, it may
   clear the connection and forward the RST to E-A saving an incorrect
   sequence number.  [...]

and:
                             vv          vv   v
             [...].  This RST, will again, not acceptable and may
   trigger a challenge ACK.
---                          v          v    vv
             [...].  This RST will again not be acceptable and may
   trigger a challenge ACK.

2nd paragraph:

   The above situation may result in a RST/ACK war.  However we believe
   that if such a case exists in the Internet the middle box design does
   not comply to [RFC0793].  [...]
---
|  The above situation may result in a RST/ACK war.  However, we believe  
| that if such a case exists in the Internet, the middle box design
   does not comply to [RFC0793].  [...]

(12)  Section 8.2

1st paragraph:

                      [...].  The scenario is the same as the earlier
   case, but in this case instead of sending the cached RST, the
   middlebox (M-B) sends a RST that computes its sequence number as a
   sum of the ack field in the ACK and the window advertised by the ACK
   that was sent by E-A to challenge the RST as depicted below.  [...]
---
                      [...].  The scenario is the same as the earlier
   case, but in this case instead of sending the cached RST, the
|  middlebox (M-B) sends a RST that computes its sequence number as the
   sum of the ack field in the ACK and the window advertised by the ACK
   that was sent by E-A to challenge the RST as depicted below.  [...]

(13)  Section 9, 5th paragraph

   Another consideration that should be noted is a reflector attack is
   possible with the required RST/SYN mitigation techniques.  In this
   attack an off-path attacker can cause a victim to send an ACK segment
   for each spoofed RST/SYN segment that lies within the current receive
   window of the victim.  [...]
---
|  Another consideration that should be noted is a reflector attack,  
| which is possible with the required RST/SYN mitigation techniques.
|  In this attack, an off-path attacker can cause a victim to send an
   ACK segment for each spoofed RST/SYN segment that lies within the
   current receive window of the victim.  [...]

Best regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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