On 3 Oct 2008, at 09:58, Joe Touch wrote:
As noted in the draft, this is an update to the use of the IP security option originally defined in RFC 791.
More precisely, this is an IPv6 analogue to RFC-1038, RFC-1108 and CIPSO defined in FIPS-188, each of which caused that part of RFC-791 to be deprecated. Existing MLS operating systems generally support both RFC-1108 and FIPS-188 for IPv4. The goal of this draft is to enable IPv6 to be supported in addition to IPv4 in an interoperable and openly-specified manner.
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.
To the extent that is true, that part of RFC-791 has been ignored for more than 20 years by both host implementers and router implementers. So far as I am aware, no deployed IP implementation has ever supported the RFC-791 security option. (There might have been some support in the early BBN routers or in MULTICS; I'm not sure about details of either of those). In the 1980s, RFC-1038 was created to support a specialised security gateway called "BLACKER" because the RFC-791 definition was not suitable. (I believe all of the BLACKER systems have been out-of-service for many many years now.) Publishing RFC-1038 deprecated RFC-791's security option. The only IP router that has had IP security option support since about 1991 is Cisco IOS, which supports only RFC-1108 and (I am told and so far as I recall from looking at the source code when I worked there) did not ever support the RFC-791 definition of the security option. On the host side, I am not aware of any non-MLS host that ever had support for the RFC-791, RFC-1038, or RFC-1108 security options.
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.
*Nothing in the draft applies "to all Internet hosts".* The draft is clear that nothing in the draft applies to any system that does not claim to implement that specific draft. I can repeat that scope comment in the document more times if that helps, but it does already clearly say that in the draft.
The draft does not appear to indicate how an MLS system would interact with legacy systems that are not updated.
No changes to legacy systems are needed.
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.
Those existing MLS implementations were the basis for the current text in this document. They did not follow either RFC-793 or RFC-1122 in this narrow respect, to the best of my knowledge. (I have specific knowledge of kernel internals for some, but not all, of the CMW products that existed in the early 1990s.) More broadly, (single-level OS) TCP and IP implementations that are deployed today do not follow RFC-791, RFC-793, or RFC-1122 in each and every detail. For openers, I don't think any implementations of the RFC-791 security option exist. ASIDE: One of the reasons that the IETF hasn't produced either a router requirements or a host requirements document for many years is that the last attempts in those areas did not have much impact, either on what implementers shipped or on what operators deployed.
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 hasimplications across the network architecture supported by MLS endsystems.
The architecture is unchanged. MLS TCP implementations do vary somewhat, as Dave Borman already noted on the IETF discuss mailing list. When one has an MLS system, conceptually one has many concurrent logically separate TCP implementations (one per sensitivity level). This draft simply describes how one maps the existing (unchanged) architecture onto an MLS OS implementation.
1. this document needs to address interactions with non-MLS updated endpoints, and whether that needs to change
I am happy to repeat in the draft that non-MLS systems do not need 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
I can't parse that sentence, so I'm a bit confused. I'm happy to edit the document text to repeat the note that nothing in the document applies to any system that does not claim to implement the document -- if that is what you are asking for.
3. this document needs a much more extensive treatment of how it changesthe Internet architecture for MLS-updated hosts and gateways
This draft is not a specification for building an MLS operating system, nor should it be. Some relevant references on MLS operating systems are included in the draft for those who want to learn more about MLS operating systems. Again, the Internet Architecture does not change. What does change are some implementation details within an MLS operating system (as compared with a traditional and much more common single-level OS). Yours, Ran rja at extremenetworks.com _______________________________________________ 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.