Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security (more time to comment!)

["Smith, Donald" <[e-mail]>]

First sorry for the late reply.
My comments are mostly areas I would reword to clarify the meaning since there wasn't a lot of technical content in this version of the draft.

I am providing the diff output to provide the original, some context and my suggested changes/questions.

smitdo@co950g02smitdo /cygdrive/c/cygwin
$ diff -b -c1 draft-ietf-tcpm-tcp-security-01.txt tcp-secure-rfc.txt

*** draft-ietf-tcpm-tcp-security-01.txt Mon Mar 22 13:02:52 2010
--- tcp-secure-rfc.txt  Mon Mar 22 13:09:59 2010



*** 231,243 ****
     The TCP/IP protocol suite was conceived in an environment that was
!    quite different from the hostile environment they currently operate
     in.  However, the effectiveness of the protocols led to their early
!    adoption in production environments, to the point that, to some
!    extent, the current world's economy depends on them.

     While many textbooks and articles have created the myth that the
!    Internet protocols were designed for warfare environments, the top
!    level goal for the DARPA Internet Program was the sharing of large
     service machines on the ARPANET [Clark, 1988].  As a result, many
!    protocol specifications focus only on the operational aspects of the
!    protocols they specify, and overlook their security implications.

--- 231,245 ----
     The TCP/IP protocol suite was conceived in an environment that was
!    a "friendly" openly sharing enviroment primairly composed of education and

! research sites. Which is quite different from the hostile environment they
! currently operate
     in.  However, the effectiveness of the protocols led to their early
!    adoption in commercial production environments, to the point that,
! portions of the current world's economy depends upon them.

     While many textbooks and articles have created the myth that the
!    Internet protocols were designed for warfare environments, the primary
! goal for the DARPA Internet Program was the sharing of large
     service machines on the ARPANET [Clark, 1988].  As a result, many
!    protocol specifications primarily focus on the operational aspects of the
!    protocols they specify, overlooking their security implications.

***************
*** 246,250 ****
     adopted by the ARPANET more than two decades ago.  During the last
!    twenty years, many vulnerabilities have been identified in the TCP/IP
     stacks of a number of systems.  Some of them were based on flaws in
!    some protocol implementations, affecting only a reduced number of
     systems, while others were based in flaws in the protocols
--- 248,252 ----
     adopted by the ARPANET more than two decades ago.  During the last
!    twenty years many vulnerabilities have been identified in the TCP/IP
     stacks of a number of systems.  Some of them were based on flaws in
!    the protocol implementations, affecting only a limited set of
     systems, while others were based in flaws in the protocols
***************
*** 258,264 ****
     Security Incident Response Teams) and vendors, which helped to raise
!    awareness about the threats and the best mitigations known at the
     time the reports were published.  Unfortunately, this also led to the
     documentation of the discovered protocol vulnerabilities being spread
!    among a large number of documents, which are sometimes difficult to
!    identify.

--- 260,267 ----
     Security Incident Response Teams) and vendors, which helped to raise
!    awareness about the threats and mitigations known at the
     time the reports were published.  Unfortunately, this also led to the
     documentation of the discovered protocol vulnerabilities being spread
!    through out  a large number of documentsMaking a holistic view of
! vulnerabilities in this suite of protocols difficult to achieve especially
! for implementation teams.

***************
*** 266,269 ****
     Internet protocols did not result in official documents (RFCs) being
!    issued by the IETF (Internet Engineering Task Force).  This basically
!    led to a situation in which "known" security problems have not always
     been addressed by all vendors.  In addition, in many cases vendors
--- 269,272 ----
     Internet protocols did not result in official documents (RFCs) being
!    issued by the IETF (Internet Engineering Task Force).  This
!    lead to a situation in which "known" security problems have not always
     been addressed by all vendors.  In addition, in many cases vendors
***************
*** 273,275 ****

!    Producing a secure TCP/IP implementation nowadays is a very difficult

--- 276,278 ----

!    Producing a less vulnerable  TCP/IP implementation is a difficult

***************

*** 284,288 ****
     a security roadmap for the protocols.  Implementers are faced with
!    the hard task of identifying relevant documentation and
!    differentiating between that which provides correct advice, and that
!    which provides misleading advice based on inaccurate or wrong
     assumptions.
--- 287,292 ----
     a security roadmap for the protocols.  Implementers are faced with
!    the complex task of identifying relevant documentation and
!    differentiating between those that provide correct advice, and those
!    that provide misleading or incomplete advice based on inaccurate or
! incorrect
     assumptions.
***************
*** 330,331 ****
--- 334,336 ----
        Option" (6 pages)
+ Tcp-AO draft ?? should be included

*** 365,366 ****
--- 370,372 ----

+
  1.3.  Organization of this document
***************
*** 369,374 ****
     contains a discussion of each of the TCP header fields, identifies
!    their security implications, and discusses the possible
     countermeasures.  The second part contains an analysis of the
     security implications of the mechanisms and policies implemented by
!    TCP, and of a number of implementation strategies in use by a number
     of popular TCP implementations.
--- 375,380 ----
     contains a discussion of each of the TCP header fields, identifies
!    their security implications, and discusses possible
     countermeasures.  The second part contains an analysis of the
     security implications of the mechanisms and policies implemented by
!    TCP and of a number of implementation strategies in use by a number
     of popular TCP implementations.
***************

*** 428,430 ****
     original specification.  RFC 2581 [Allman et al, 1999] specifies TCP
!    congestion control and avoidance mechanisms, not present in the
     original specification.  Other documents specify extensions and
--- 434,437 ----
     original specification.  RFC 2581 [Allman et al, 1999] specifies TCP
! mechanisms for
!  control and avoidanceof congestion , not present in the
     original specification.  Other documents specify extensions and
***************
*** 513,517 ****
     in response (provided that the incomming segment does not have the
!    RST flag set).

!    TCP MUST be able to grecefully handle the case where the source end-
     point (IP Source Address, TCP Source Port) is the same as the
--- 520,525 ----
     in response (provided that the incomming segment does not have the
!    RST flag set). (wouldn't this cause the reset to have 0 as the source or
! destination which would cause a reset back, giving us a ping pong effect?

!    TCP MUST be able to gracefully handle the case where the source end-
     point (IP Source Address, TCP Source Port) is the same as the
***************
*** 521,523 ****
     is in the LISTEN or CLOSED states for use as ephemeral ports, as this
!    could allow attackers on the local system to "steal" incomming TCP
     connections.
--- 529,531 ----
     is in the LISTEN or CLOSED states for use as ephemeral ports, as this
!    could allow attackers on the local system to "steal" incoming TCP
     connections.
***************
*** 543,547 ****
     unique (not currently in use by any other transport protocol
!    instance).

     In most of the discussion we refer to client-side (or "ephemeral")
     port-numbers and server-side port numbers, since that distinction is
--- 551,558 ----
     unique (not currently in use by any other transport protocol
!    instance). (then doesn't this need to be 5tuple including ip protocol?)

     In most of the discussion we refer to client-side (or "ephemeral")
+ client side doesn't have to be ephermeral many tcp protocols use the same
+ port for both client and server (trandionally). Ephemeral means short lived
+ (daily).
     port-numbers and server-side port numbers, since that distinction is
***************

*** 562,565 ****

!    port 0, an ephemeral port is selected for the corresponding TCP end-
!    point.  As a result, the TCP port number 0 is never actually used in
     TCP segments.
--- 573,578 ----

!    port 0, an port from the systems "ephemeral port range" is selected for
! the corresponding TCP end-
!    point.  As a result, the TCP port number 0 should never actually be used
! in TCP segments.
***************
*** 570,572 ****
     of 0 are usually employed for remote OS detection via TCP/IP stack
!    fingerprinting [Jones, 2003].

--- 583,586 ----
     of 0 are usually employed for remote OS detection via TCP/IP stack
!    fingerprinting [Jones, 2003]. Additionally ip fragements don't have a port

! number filled in which most systems interpret as port 0/0.

***************
*** 582,587 ****
     an RST (provided these incoming segments do not have the RST bit
!    set).

     Responding with an RST segment to incoming segments that have the RST
!    bit would open the door to RST-war attacks.

--- 596,601 ----
     an RST (provided these incoming segments do not have the RST bit
!    set) or do silent drop?

     Responding with an RST segment to incoming segments that have the RST
!    bit would open the door to infinite RST loop attacks.

***************
*** 595,597 ****
     legitimate scenarios, TCP should nevertheless be able to process them
!    without the need of any "extra" code.

--- 609,612 ----
     legitimate scenarios, TCP should nevertheless be able to process them
!    without the need of any "extra" code.
+ Of course there is "extra" code required you have to do a sanity check.

***************


*** 651,652 ****
--- 666,669 ----
     connection in any state other than the fictional state CLOSED.  This
+ Not fictional maybe incorrectly identifed? And here you use conection id's
+ which I believe is the four-tuple but isn't clearly called out as such.
     can be problematic in scenarios in which a client establishes
***************


(coffee != sleep) & (!coffee == sleep)
[e-mail] gcia

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Fernando Gont
> Sent: Thursday, March 11, 2010 10:01 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [tcpm] Feedback request on
> draft-ietf-tcpm-tcp-security (more time to comment!)
>
> Folks,
>
> Some of you had expressed interest in providing feedback on the
> aforementioned I-D. However, so far only a one person (Wes) has sent
> feedback.
>
> Given that more comments are needed, and that the last few weeks have
> probably been particularly busy (IETF I-D submission
> cut-off's), we have
> extended the period of time to send comments on
> draft-ietf-tcpm-tcp-security-01.txt
> (http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt).
>
> I'm requesting feedback on all the sections through Section
> 3.1.2.3. -- this includes the introduction sections, the basic
> check on the TCP segment size (Section 3) and the discussion of port
> numbers (Section 3.1 with all its subsections).
>
> Please review these sections and submit comments by Monday March 22nd,
> 2010, so that we can move on to the next sections in a timely manner.
>
> Thanks!
> --
> 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://www.ietf.org/mailman/listinfo/tcpm
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.