-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 08:30:01 -0700 > Joe Touch <touch at ISI.EDU> wrote: > >> If you follow the implications of " With respect to a given network, >> each distinct Sensitivity Label represents a separate virtual network >> which shares the same physical network.", and the way it impacts TCP, >> can you explain how the current draft indicates how to similarly >> virtualize any of the following? >> >> - - ICMP handling >> - - forwarding >> - - routing >> - - IPv6 neighbor discovery >> - - IGMP >> - - PIM >> - - IPsec >> - - IPIP tunnels >> - - firewalls >> >> All of these things use IP addresses as unique identifiers, and all >> are affected by extending that space to use the pair [address, >> security level] instead. >> > Without trying to answer in detail, the basic rule is simple: no data > with a given security label should eveFrom saag-bounces at ietf.org Fri Oct 3 09:47:28 2008 Return-Path: <saag-bounces at ietf.org> X-Original-To: saag-archive at ietf.org Delivered-To: ietfarch-saag-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66BF3A68DB; Fri, 3 Oct 2008 09:47:28 -0700 (PDT) X-Original-To: saag at core3.amsl.com Delivered-To: saag at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E093A68DB; Fri, 3 Oct 2008 09:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599] 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 XgmiyoW69r3g; Fri, 3 Oct 2008 09:47:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AB84C3A67E7; Fri, 3 Oct 2008 09:47:26 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m93GlJvp011965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 09:47:21 -0700 (PDT) Message-ID: <48E64C94.4040708 at isi.edu> Date: Fri, 03 Oct 2008 09:47:16 -0700 From: Joe Touch <touch at ISI.EDU> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Steven M. Bellovin" <smb at cs.columbia.edu> References: <tslprmm3gjs.fsf at mit.edu> <20080929170305.4740f779 at cs.columbia.edu> <tslljx9zzdu.fsf at mit.edu> <20081001221217.3921b69e at cs.columbia.edu> <20081002093129.5bb80658 at cs.columbia.edu> <48E51069.1040403 at isi.edu> <200810021857.m92IvIYY027621 at vapor.isi.edu> <48E552AD.2080209 at isi.edu> <200810030016.m930GgJM015855 at vapor.isi.edu> <48E56BC7.4020302 at isi.edu> <20081002210659.23e96035 at cs.columbia.edu> <48E5712B.8020305 at isi.edu> <602844BA-9D1F-459E-BCA0-352695349BD9 at nokia.com> <611786CF-F5C6-4881-B370-3294F689EDCD at extremenetworks.com> <48E624F5.7000203 at isi.edu> <1223044364.21925.20.camel at localhost> <48E63A79.1020708 at isi.edu> <20081003124148.18a6a94f at cs.columbia.edu> In-Reply-To: <20081003124148.18a6a94f at cs.columbia.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch at isi.edu Cc: draft-stjohns-sipso-05 at tools.ietf.org, TSV Area <tsv-area at ietf.org>, saag at ietf.org Subject: Re: [saag] draft-stjohns-sipso-05 & transport protocols X-BeenThere: saag at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group <saag.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/saag> List-Post: <mailto:saag at ietf.org> List-Help: <mailto:saag-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request at ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces at ietf.org Errors-To: saag-bounces at ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Fri, 03 Oct 2008 08:30:01 -0700 > Joe Touch <touch at ISI.EDU> wrote: > >> If you follow the implications of " With respect to a given network, >> each distinct Sensitivity Label represents a separate virtual network >> which shares the same physical network.", and the way it impacts TCP, >> can you explain how the current draft indicates how to similarly >> virtualize any of the following? >> >> - - ICMP handling >> - - forwarding >> - - routing >> - - IPv6 neighbor discovery >> - - IGMP >> - - PIM >> - - IPsec >> - - IPIP tunnels >> - - firewalls >> >> All of these things use IP addresses as unique identifiers, and all >> are affected by extending that space to use the pair [address, >> security level] instead. >> > Without trying to answer in detail, the basic rule is simple: no data > with a given security label should ever be senr be sent to or through an entity > with a different label. Routers and links are typically multi-label, > so they can accept data within a range of levels. A process will > always be single-level, so it can only accept data -- TCP, ICMP > replies, etc. -- at exactly the same level. There are exceptions -- > IPsec boxes would (in that environment) be trusted to downgrade > information, i.e., accept sensitive data, encrypt it, and send out the > ciphertext packets with a different label. IGMP poses a fascinating > problem; I don't know that anyone has ever worked out the implications > of doing that in an MLS environment. Understood; the issue is that this document, if intended to extend MLS into the architecture of MLS-enabled hosts, needs to be augmented substantially to address these issues - even if to declare some out of scope and not supported. I don't know if it's tenable to assert that only the transport protocols of interest are virtualized. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmTJMACgkQE5f5cImnZruP/ACcCyIsnvOGEsUnZAMmtd7Rclcs EkgAoM067VmD0jY4TGdrIdyQGhMwizjz =LNbL -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag at ietf.org https://www.ietf.org/mailman/listinfo/saag t to or through an entity > with a different label. Routers and links are typically multi-label, > so they can accept data within a range of levels. A process will > always be single-level, so it can only accept data -- TCP, ICMP > replies, etc. -- at exactly the same level. There are exceptions -- > IPsec boxes would (in that environment) be trusted to downgrade > information, i.e., accept sensitive data, encrypt it, and send out the > ciphertext packets with a different label. IGMP poses a fascinating > problem; I don't know that anyone has ever worked out the implications > of doing that in an MLS environment. Understood; the issue is that this document, if intended to extend MLS into the architecture of MLS-enabled hosts, needs to be augmented substantially to address these issues - even if to declare some out of scope and not supported. I don't know if it's tenable to assert that only the transport protocols of interest are virtualized. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmTJMACgkQE5f5cImnZruP/ACcCyIsnvOGEsUnZAMmtd7Rclcs EkgAoM067VmD0jY4TGdrIdyQGhMwizjz =LNbL -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag at ietf.org https://www.ietf.org/mailman/listinfo/saag
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.