[tcpm] TCP secure

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Thu, 03 January 2008 21:05 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAXGJ-0001l5-J0; Thu, 03 Jan 2008 16:05:59 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAXGI-0001et-In for tcpm-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 16:05:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAXGI-0001cB-5j for tcpm@ietf.org; Thu, 03 Jan 2008 16:05:58 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAXGH-0008Lr-Co for tcpm@ietf.org; Thu, 03 Jan 2008 16:05:58 -0500
X-IronPort-AV: E=Sophos;i="4.24,240,1196668800"; d="scan'208";a="30024081"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Jan 2008 13:05:56 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m03L5ucU004188; Thu, 3 Jan 2008 13:05:56 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m03L5qHC018047; Thu, 3 Jan 2008 21:05:56 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 13:05:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 03 Jan 2008 13:05:52 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC58047D6091@xmb-sjc-21c.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: TCP secure
Thread-Index: AchOTGxU+YLeyjV5T12k8IIaALueMA==
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
X-OriginalArrivalTime: 03 Jan 2008 21:05:55.0815 (UTC) FILETIME=[6E7BD770:01C84E4C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2938; t=1199394356; x=1200258356; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20TCP=20secure=20 |Sender:=20; bh=zGTkWjLuLsQ5z4c7iSENK/Erq4zueyTaDsVUrmmQCzY=; b=RkJPz+HoxLawpAMrlvZkRQhM6u16PaJKvoWT/f1dkuDlvD6CdXM3cyxIzX Z+8piNB9446eVcTZ6stKKU78LbvCquYIUo/ojlIqT/CggTW9Mra2m+nofONZ SI2CKlDv3p;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: Ted Faber <faber@isi.edu>, mallman@icir.org
Subject: [tcpm] TCP secure
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Greetings,
       
The following note pertains to the TCP secure document and the hope is
to get this to WGLC once the pending issues are resolved.

Summary
=======

After the presentation in the Chicago IETF and the follow up discussions
on the mailing list w.r.t the strength of the mitigations, the outcome
of which was to have an applicability statement and then go about
getting consensus on the strength of each individual mitigation. To
quote Mark Allman :

<BEGIN QUOTE>

  It seems to me that this discussion is really divergent because there
  is no applicability statement in the document, per Lars' comment.  I
  wonder if you guys could go off and generate such a statement and then
  we could re-visit this question.  I think that would factor things
  into a question of "where" this is applicable and then how strongly we
  want to advocate these mitigations within that context.  Is that
  reasonable?

<END QUOTE>

There was a discussion in which some folks mentioned how the AS should
be structured. We have attempted to capture this and what follows is the
sample AS.

========================================================================
==============
APPLICABILITY STATEMENT

The mitigations presented in this document talks about some known
in-window attacks and the solutions to the same. The mitigations
suggested in this draft SHOULD (RECOMMENDED) be implemented in devices
where the TCP connections are most vulnerable to the attacks described
in this document.  Some examples of such TCP connections are the ones
that tend to be long-lived where the connection end points can be
determined, in cases where no auxiliary anti-spoofing protection
mechanisms like TCP MD5 can be deployed. TCP secure MAY (OPTIONAL) be
implemented in other cases. 
========================================================================
================

It would be nicer if folks can comment on the 

A) AS and suggest any modifications.

B) choose the strength of each mitigation WITH reasoning.


My vote 
=======

Since AS covers the main concern, my vote would go for all MUST's or
SHOULD's.

Reason for picking MUST's or SHOULD's : 

With AS in place, the document has given enough leeway for implementers
to pick and chose whether one wants to implement TCP secure or not.
These mitigations are important since it increases TCP's robustness to
various attacks described in the document. Hence I would color them as
MUST's or SHOULD's.

Thanks,
Anantha


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm