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

"Anantha Ramaiah \(ananth\)" <ananth@cisco.com> Wed, 26 September 2007 23:29 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 1IagK3-0004eI-VG; Wed, 26 Sep 2007 19:29:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagK3-0004dx-03 for tcpm@ietf.org; Wed, 26 Sep 2007 19:29:39 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IagJt-0003wn-Qn for tcpm@ietf.org; Wed, 26 Sep 2007 19:29:38 -0400
X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="20248358"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 16:29:29 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8QNTTwe011641; Wed, 26 Sep 2007 16:29:29 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8QNTTTo005462; Wed, 26 Sep 2007 23:29:29 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 16:29:29 -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 16:29:27 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580405246A@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <46FADB17.2060008@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] tcpsecure: how strong to recommend?
Thread-Index: AcgAjcUl981d9xFlQEyXg3fRKCbmNAABNo/g
From: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
To: "Joe Touch" <touch@ISI.EDU>
X-OriginalArrivalTime: 26 Sep 2007 23:29:29.0068 (UTC) FILETIME=[157CB2C0:01C80095]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2086; t=1190849369; x=1191713369; c=relaxed/simple; s=sjdkim3002; 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=l06Sji2u7e6eVlFCgr+WNzIyT7QOKyO0tztR6SarnMs=; b=mOJAEgNlIzoxq/9na/io4locOhkWeug+zBwOaR4b8Pfr9rLcR49edzYbjTdmiFRZcPcyvxKg kQIBGpsv0c0TVmfbhltp33bamA2lX5UMKk6VmF2tfqjpF02ZTBnYSy+x;
Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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:
> > Inline comments....
> ...
> > - Like someone pointed out MAY is a weak statement, it could also 
> > imply "MAY not". Why should it be a MAY when we know that 
> the pros of 
> > the soultion outweigh the cons?
> 
> They do not in all cases. If TCP is deployed either where no 
> well-known connections exist, or where such connections are 
> protected by other authentication, this solution adds
> 	a) complexity

"complexity" and the strength of mitigation cannot be tied together,
IMO.

Almost every solution that tries to add/modify/delete some TCP behaviour
does add complexity to TCP processing.

That said, we have already debated in the past, about the so called
"complexity" of these solutions.


> 	b) chatter during valid RSTs

You mean an extra RTO? Ok, fair enough. But, benefits outweigh
drawbacks, I would think.

> 	c) IPR encumberance

AFAIK, this is not an issue as this was beaten to death before.

> 
> > - to me these recommendations are good to have,
> 
> You're now making decisions for others, i.e., these 
> recommendations are "good for everyone to have unless they 
> have a reason not to". That's not what you said before in 
> terms of "let the user/implementer decide".

"Good to have" since it improves TCP robustness and quality, this is my
viewpoint. This is different from "making decisions for others".

> 
> ...
> >> There's no MUST in that logic, any more than 'you MUST deploy 
> >> IPsec/BTNS/TCP-MD5++'.
> > 
> > I am assuming it is a conditional MUST like "if you need 
> security then 
> > use TCP MD5", correct? Is "conditional MUST = SHOULD" ?
> 
> It is a conditional SHOULD, i.e., a SHOULD with a caveat. 
> From the RFC2119-level, IMO that's a MAY with explanation.

Curious : Are you ok tagging the TCP secure mitigations with a
"conditional SHOULD" or "SHOULD with caveat" or "an applicability
statement with a SHOULD"? I am assuming that these are equivalent to MAY
with explanation? 

-Anantha

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