RE: [tcpm] tcpsecure: how strong to recommend?

"Anantha Ramaiah \(ananth\)" <ananth@cisco.com> Wed, 26 September 2007 18:33 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 1IabhM-0006Om-41; Wed, 26 Sep 2007 14:33:24 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabhK-0006Of-Pg for tcpm@ietf.org; Wed, 26 Sep 2007 14:33:22 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IabhK-0001pV-Ah for tcpm@ietf.org; Wed, 26 Sep 2007 14:33:22 -0400
X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="225631549"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2007 11:33:21 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8QIXLxV023581; Wed, 26 Sep 2007 11:33:21 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QIXL8p024310; Wed, 26 Sep 2007 18:33:21 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); Wed, 26 Sep 2007 11:33:21 -0700
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
Subject: RE: [tcpm] tcpsecure: how strong to recommend?
Date: Wed, 26 Sep 2007 11:33:19 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5804052217@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <46FAA166.8020403@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] tcpsecure: how strong to recommend?
Thread-Index: AcgAaR/I8v3Z5aKtTKKO00yNZzUhqAAAF7uA
From: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
To: "Joe Touch" <touch@ISI.EDU>
X-OriginalArrivalTime: 26 Sep 2007 18:33:21.0393 (UTC) FILETIME=[B720A610:01C8006B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2462; t=1190831601; x=1191695601; 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:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=D2cqVLP67+yZ+RAs5d9kZnMNZBa15pqe9qWTPa3A7fo=; b=Wkjy5d0meOU3NIHxO+NDmyTjgEPOO6MXjrDYUn7Z0L0fY/NqOY3Escjm0fWFc1PhcFrSs5So lZHIlRouIyq9hmaq6/mGWP8luVcdUFcRKSRjFdQnJZrRRSApN0g4sVkA;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: tcpm@ietf.org, Tim Shepard <shep@alum.mit.edu>
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

 
> 
> 
> Anantha Ramaiah (ananth) wrote:
> > Few points :-
> > 
> > - It is true that TCP secure recommendations might be 
> useful for long 
> > lived sessions like BGP. But there are many applications using TCP 
> > which also could benefit from the proposed changes.
> 
> As an aside, it would be useful to provide in your doc an 
> example of such an application, e.g., where the endpoints and 
> port numbers are known or reasonably guessable.

We can give it a thought about adding something if the WG feels so. I
for one feel that we would want to preserve the generic nature of this
document, you want to avoid listing application references as much as
possible, we can give examples but as you it wouldn't be a complete
list, anyways.

> 
> > The TCP secure changes
> > needs to be viewed as a standalone thing, since it focusses in 
> > providing robustness to TCP connections w.r.t some spoofing attacks.
> 
> The real point is that spoofing isn't a standalone thing. 
> Putting protections into TCP without locking down ICMP isn't 
> sufficient, and inferring authentication from header 
> properties just narrows the window of attack.

If we have to fix multiple layers, lets fix it, I have no problems. You
can do all at once or piecemeal, as simple as that. It doesn't matter
whether spoofing is standalone or not, it is about how well you can make
your TCP stack respond to such malicious attacks, if you care to do so.

> 
> > - TCP secure, TCP MD5, TCP advanced security algorithms, 
> IPsec are all 
> > different tools with varying degrees of complexity and 
> usage. A user 
> > can chose to use one of them depending on his/her requirements. 
> > Telling people to only use IPsec is akin to saying "always fly in 
> > business class". Yes I have used this analogy before, but 
> this is one 
> > whih popped up in mind after today's coffee :-)
> 
> If we agree that users should be able to choose the solution 
> that fits, let's go with MAYs all around.

I know you want all MAY's in place. Some others (includes me) are not
yet convinced that why SHOULD doesn't provide the same assurance.

> 
> Otherwise, aren't you dictating your solution as fitting 
> everyone's needs?

I am not "dictating" anything here. I am just supporting the reason why
I feel it should be SHOULD's :-) 

-Anantha
> 
> Joe
> 
> 

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