-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I've made several points on this matter on the original thread on the main IETF list. I'll summarize a few below, in the context of Ran's overview. RJ Atkinson wrote: > > On 3 Oct 2008, at 03:15, Lars Eggert wrote: >> For those of you who haven't followed the discussion so far on the >> main IETF list, Section 7.3 of this draft proposes that TCP and SCTP >> connections are now uniquely identified by a five-tuple consisting of >> source and destination IP addresses and ports as well as the >> sensitivity label. > > Hi, > > There appear to be several points of confusion within Lars' > note. Please let me try to clarify what the draft actually > says and doesn't say: > > 0) Background about MLS operating systems: > I think a major point of confusion relates to multi-level > secure (MLS) operating systems, which most IETF folks have > never encountered and many have never even heard about. > In an MLS operating system, the OS provides mandatory > access From saag-bounces at ietf.org Fri Oct 3 06:58:01 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 171503A69EA; Fri, 3 Oct 2008 06:58:01 -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 41B023A69EA; Fri, 3 Oct 2008 06:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 YKcNd2Zo5ONn; Fri, 3 Oct 2008 06:57:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2D8B23A6859; Fri, 3 Oct 2008 06:57:59 -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 m93DwD8H015215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 06:58:15 -0700 (PDT) Message-ID: <48E624F5.7000203 at isi.edu> Date: Fri, 03 Oct 2008 06:58:13 -0700 From: Joe Touch <touch at ISI.EDU> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RJ Atkinson <rja at extremenetworks.com> 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> In-Reply-To: <611786CF-F5C6-4881-B370-3294F689EDCD at extremenetworks.com> 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 Hi, all, I've made several points on this matter on the original thread on the main IETF list. I'll summarize a few below, in the context of Ran's overview. RJ Atkinson wrote: > > On 3 Oct 2008, at 03:15, Lars Eggert wrote: >> For those of you who haven't followed the discussion so far on the >> main IETF list, Section 7.3 of this draft proposes that TCP and SCTP >> connections are now uniquely identified by a five-tuple consisting of >> source and destination IP addresses and ports as well as the >> sensitivity label. > > Hi, > > There appear to be several points of confusion within Lars' > note. Please let me try to clarify what the draft actually > says and doesn't say: > > 0) Background about MLS operating systems: > I think a major point of confusion relates to multi-level > secure (MLS) operating systems, which most IETF folks have > never encountered and many have never even heard about. > In an MLS operating system, the OS provides mandatory > access controlscontrols that separate users and data according to > a lattice. Users have "clearances", while data have > "sensitivity labels". These labels primarily are two > dimensional. One traditionally thinks of a vertical axis > consisting (bottom to top) as: System Low, Unclassified, > Secret, Most Secret, System High. One traditionally > thinks of a horizontal axis consisting of various compartments > (e.g. NATO, UK, RU). The OS ensures that users with lower > clearances are not even aware of the existence of data > outside their clearance. As noted in the draft, this is an update to the use of the IP security option originally defined in RFC 791. Interactions between that option and TCP were specified in RFC 793, and this document changes that behavior very dramatically. > 1) No change is proposed to TCP in general: > There is *no* proposal to change how TCP or SCTP connections > are identified or implemented for any system that does NOT > claim to implement this MLS label specification. Granted that the IP security option is not *used* except on MLS endpoints, but note that: - RFC 791 specifies that the IP security option must be implemented in all hosts and gateways; its _USE_ may be optional, but its *implementation* is not optional. - RFC 793 specifies current interaction with that option, and 1122 reinforces that interaction, which specifies behavior even when the option is not used in packets emitted by the host There appears to be at least one change that might be required by all Internet hosts; current behavior upon receipt of an IP packet at a security level not supported is to send a TCP RST. This document indicates that such hosts MUST silently drop such packets. > 2) MLS operating systems have different requirements: > In turn, this specification *only* applies to Multi-Level > Secure (MLS) operating systems that choose to implement > this particular IPv6 labelling specification. The draft > is very clear about this. The draft does not appear to indicate how an MLS system would interact with legacy systems that are not updated. > 3) The MLS-specific proposal is accepted by long-term > members of the Transport community: > Please see Dave Borman's note to the IETF discuss > list from yesterday. Dave has about as much TCP > experience as anyone. I consider it very incomplete with regard to the impact of the changes proposed on the architecture of MLS endpoints. > 4) Nothing new is being proposed for the transport layer: > This shipped about 20 years ago. So we have about 20 > years of operational experience that the description in > this draft is correct for an MLS operating system. I'm presuming that implementations prior to this update implemented the IP option handling in RFC 793 and 1122. This document changes that quite a bit. ... > 5) This draft doesn't propose to change the transport > architecture: Section 7.3.1 requires that the transport architecture for MLS endsystems uses a 5-tuple to identify TCP endpoints. That has implications across the network architecture supported by MLS endsystems. > 6) This draft has has broad review from users who have MLS > deployments and from implementers of MLS systems: - ---- Overall, my concerns are that: 1. this document needs to address interactions with non-MLS updated endpoints, and whether that needs to change 2. this document needs to explicitly indicate that it overrides RFCs 791, 793, and 1122 in allowing the implementation of changes to be optional for hosts not *using* MLS 3. this document needs a much more extensive treatment of how it changes the Internet architecture for MLS-updated hosts and gateways I remain concerned that this last item is complex, and certainly incomplete at this point. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmJPQACgkQE5f5cImnZrt0wwCg9peX02r44U4uFbpxsTDzfwYs NCkAnj8Ct62v9rsaJmyIWcSmuTlQUXEa =VnIR -----END PGP SIGNATURE----- ________________ that separate users and data according to > a lattice. Users have "clearances", while data have > "sensitivity labels". These labels primarily are two > dimensional. One traditionally thinks of a vertical axis > consisting (bottom to top) as: System Low, Unclassified, > Secret, Most Secret, System High. One traditionally > thinks of a horizontal axis consisting of various compartments > (e.g. NATO, UK, RU). The OS ensures that users with lower > clearances are not even aware of the existence of data > outside their clearance. As noted in the draft, this is an update to the use of the IP security option originally defined in RFC 791. Interactions between that option and TCP were specified in RFC 793, and this document changes that behavior very dramatically. > 1) No change is proposed to TCP in general: > There is *no* proposal to change how TCP or SCTP connections > are identified or implemented for any system that does NOT > claim to implement this MLS label specification. Granted that the IP security option is not *used* except on MLS endpoints, but note that: - RFC 791 specifies that the IP security option must be implemented in all hosts and gateways; its _USE_ may be optional, but its *implementation* is not optional. - RFC 793 specifies current interaction with that option, and 1122 reinforces that interaction, which specifies behavior even when the option is not used in packets emitted by the host There appears to be at least one change that might be required by all Internet hosts; current behavior upon receipt of an IP packet at a security level not supported is to send a TCP RST. This document indicates that such hosts MUST silently drop such packets. > 2) MLS operating systems have different requirements: > In turn, this specification *only* applies to Multi-Level > Secure (MLS) operating systems that choose to implement > this particular IPv6 labelling specification. The draft > is very clear about this. The draft does not appear to indicate how an MLS system would interact with legacy systems that are not updated. > 3) The MLS-specific proposal is accepted by long-term > members of the Transport community: > Please see Dave Borman's note to the IETF discuss > list from yesterday. Dave has about as much TCP > experience as anyone. I consider it very incomplete with regard to the impact of the changes proposed on the architecture of MLS endpoints. > 4) Nothing new is being proposed for the transport layer: > This shipped about 20 years ago. So we have about 20 > years of operational experience that the description in > this draft is correct for an MLS operating system. I'm presuming that implementations prior to this update implemented the IP option handling in RFC 793 and 1122. This document changes that quite a bit. ... > 5) This draft doesn't propose to change the transport > architecture: Section 7.3.1 requires that the transport architecture for MLS endsystems uses a 5-tuple to identify TCP endpoints. That has implications across the network architecture supported by MLS endsystems. > 6) This draft has has broad review from users who have MLS > deployments and from implementers of MLS systems: - ---- Overall, my concerns are that: 1. this document needs to address interactions with non-MLS updated endpoints, and whether that needs to change 2. this document needs to explicitly indicate that it overrides RFCs 791, 793, and 1122 in allowing the implementation of changes to be optional for hosts not *using* MLS 3. this document needs a much more extensive treatment of how it changes the Internet architecture for MLS-updated hosts and gateways I remain concerned that this last item is complex, and certainly incomplete at this point. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmJPQACgkQE5f5cImnZrt0wwCg9peX02r44U4uFbpxsTDzfwYs NCkAnj8Ct62v9rsaJmyIWcSmuTlQUXEa =VnIR -----END PGP SIGNATURE----- _______________________________________________________ saag mailing list saag at ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________ 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.