Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

"Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov> Fri, 05 March 2010 15:10 UTC

Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC54E3A8FB9 for <tcpm@core3.amsl.com>; Fri, 5 Mar 2010 07:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level:
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnPQcWsGy9mV for <tcpm@core3.amsl.com>; Fri, 5 Mar 2010 07:10:33 -0800 (PST)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 1DE4B3A8FC0 for <tcpm@ietf.org>; Fri, 5 Mar 2010 07:10:32 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 880313284CD; Fri, 5 Mar 2010 09:10:34 -0600 (CST)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o25FAY15021358; Fri, 5 Mar 2010 09:10:34 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 5 Mar 2010 09:09:45 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov>
To: Fernando Gont <fernando@gont.com.ar>
Date: Fri, 5 Mar 2010 09:09:43 -0600
Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security
Thread-Index: Acq7PvM2ce4UTMvyT0y++Jwohr9hXwBMvZ3A
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB47DE9A7498@NDJSSCC01.ndc.nasa.gov>
References: <4B7F2881.7000700@gont.com.ar> <C304DB494AC0C04C87C6A6E2FF5603DB47DE76AE73@NDJSSCC01.ndc.nasa.gov> <4B8F050C.9070003@gont.com.ar>
In-Reply-To: <4B8F050C.9070003@gont.com.ar>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-05_12:2010-02-06, 2010-03-05, 2010-03-05 signatures=0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2010 15:10:38 -0000

>-----Original Message-----
>From: Fernando Gont [mailto:fernando@gont.com.ar]
>Sent: Wednesday, March 03, 2010 7:56 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>
> ...
>
>I have no problem with numbering each requirement.
>
>That said, what naming scheme are you thinking of? Flat, or what?
>


It doesn't really matter to my; my only concern was
that they each have a unique identifier to reference
against more easily than using the full sentence.
In order to not cause massive renumberings when
adding or removing, one system would be to name them
something like "R.0302001" for the first requirement
in section 3.2 and "R.1100012" for the twelfth one in
section 11 (with no subsections).  There may be a
more elegant way, I don't really care what the ID
looks like as long as there is one :).

If it's too much trouble or nobody else in the WG
cares, I don't think it's absolutely necessary, I
just would find it really helpful in my work.


>> Regarding the requirement:
>> """
>>    If a segment is received with port 0 as
>>    the Source Port or the Destination Port, a RST segment SHOULD be
>sent
>>    in response (provided that the incomming segment does not have the
>>    RST flag set).
>> """
>> The rationale indicates that this is to mitigate against OS
>> fingerprinting,
>
>Actually, it's almost impossible to use port 0 reliably (many
>middle-boxes already filter it, and many end-hosts do not allow its
>use). So *that* is the reason for not using it.
>
>> but no discussion motivates this particular response
>> rather than other alternatives e.g. simply ignoring the segment,
>sending
>> an ICMP port-unreachable, etc.  If there is a specific reason that
>this
>> response is the one chosen to make all implementations look the same
>to
>> a fingerprinting attempt, then we need to explain that,
>
>Agreed. The rationale for that response was "responsiveness" -- i.e.,
>rather than letting the connection-establishment time-out, you send an
>RST.
>
>But please let me give this one another thought....


I agree that the port can't and shouldn't be used,
but if we're starting with the assumption that it's
never legitimately used, then why would we worry
about making a timely response to incoming packets
on that port? I think it's easier to just ignore
them.  It's like sending responses to spam otherwise.


>
>
>> Regarding the requirement:
>> """
>>    Middle-boxes such as packet filters MUST NOT assume that clients
>use
>>    port numbers from only the Dynamic or Registered port ranges.
>> """
>> It's not clear to me how this improves security.
>
>Disclaimer: I must say I wasn't sure about including this one as a
>"requirement" (as this req does not aim at end-systems).
>
>That said, while this does not improve the security of end-systems, it
>provides advice on how to set policies correctly, so that communication
>is not blocked mistakenly. (i.e., a middle-box must not assume that
>clients only use port numbers in that range as the source port).


Ok; but implementing this requirement doesn't at all
improve the security of TCP implementations, so I
believe it's out of scope.  It seems like something
that would be included in BEHAVE's work (and maybe
it already is?), but I've not been active in that
so I could be wrong.

--
Wes Eddy
MTI Systems