[tcpm] [Fwd: Re: Secdir Review of draft-stjohns-sipso-05]

Joe Touch <touch@ISI.EDU> Thu, 02 October 2008 18:44 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id BD42228C134; Thu, 2 Oct 2008 11:44:23 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8424028C24B; Thu, 2 Oct 2008 11:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id zLwKc5hQH-yi; Thu, 2 Oct 2008 11:44:21 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu []) by core3.amsl.com (Postfix) with ESMTP id 9A1F23A68E1; Thu, 2 Oct 2008 11:44:21 -0700 (PDT)
Received: from [] (23.sub-75-215-151.myvzw.com []) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92IhYOe023699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 11:43:37 -0700 (PDT)
Message-ID: <48E51655.20207@isi.edu>
Date: Thu, 02 Oct 2008 11:43:33 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080914)
MIME-Version: 1.0
To: TSV Area <tsv-area@ietf.org>, tcpm Extensions WG <tcpm@ietf.org>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Subject: [tcpm] [Fwd: Re: Secdir Review of draft-stjohns-sipso-05]
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: <https://www.ietf.org/mailman/private/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>
Content-Type: multipart/mixed; boundary="===============1729254784=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

FYI - discussion is happening over on the main list.

--- Begin Message ---
Hash: SHA1

Steven M. Bellovin wrote:
> On Wed, 1 Oct 2008 22:12:17 -0400
> "Steven M. Bellovin" <smb@cs.columbia.edu> wrote:
>>>     Steven> Note 7.3.1 on
>>>     Steven> TCP considerations.  (Also note that 7.3.1 disagrees
>>>     Steven> with 793 on the treatment of security labels in section
>>>     Steven> 3.6 of 793.  At the least, this shoudl be noted.
>>> I had completely missed this.  I'll call out the section to the
>>> transport ADs
>> I should have added: I think the new document is in fact more correct
>> than 793 -- the 793 scheme would permit various forms of
>> high-bandwidth covert channels to be set up.  This is an issue that
>> was not nearly that well understood when 793 was written.  That said,
>> it is a change to TCP, and needs to be treated as such.
> Thinking further -- I suspect that the right thing to do here is for
> someone to write a short, simple draft amending 793 -- it's handling of
> the security option is simply wrong, independent of this draft.  I
> wonder -- what TCPs actually implement even 793?  NetBSD doesn't; I
> strongly suspect that no BSDs do.  Does Solaris?  Linux?

First, I don't agree with this document's recommendation in section 7.3.1.

TCP's current definition of a connection is:

	local IP address
	remote IP address
	local port
	remote port
	protocol (e.g., TCP)

I don't agree that treating each sensitivity level as a separate virtual
network (Sec 3 of this ID) is the appropriate analogy. If that were the
case, we'd need to redefine every Internet protocol to understand the
pair [address, sensitivity level] as an identifier, and that is not
realistic. Further, if we did need to do such an extension, there are
other equally (or arguably more) worthy candidates, notably VPN-ID.

I.e., I don't think this needs to update 793 - it needs to redefine the
Internet architecture in places like 1122, 1123, and 1812, and flow down
through all protocols they impact to make this sort of change, and I
don't see a reason to do so solely for this issue.

Overall, I see no reason why 793's current rules aren't sufficient to
emulate the desirable separation of sensitivity levels without extending
this to true virtualization. I.e., the current rule (in 793, sec 3.6,

	- match the levels proposed by both ends of the connection
	where there is a mismatch, terminate the connection

I.e., I don't see how to extend TCP to support concurrent connections
with matching connection identifiers on different sensitivity levels
without rearchitecting the entire Internet. AFAICT, it's sufficient to
allow each TCP connection to have exactly one sensitivity level, as is
already currently required.


Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

--- End Message ---
tcpm mailing list