-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ran, Thanks for the context below. Additional notes are interspersed. RJ Atkinson wrote: > > On 3 Oct 2008, at 09:58, Joe Touch wrote: ... >>> 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. It would be useful to understand "support". I would not expect most deployed implementations to emit packets with that option, but I would expect deployed implementations to check that option if it was received, and match it as specified in RFC 793. >> 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. I expected to find that kind of phrase in any one of the following locations, and did not (can you point it out if I missed it?): *- the abstract *- the intro *- intent and applicability *- definition of an endsystem *- definition of an intermediate system - architecture *- defaults - format I didn't expect to see it in all locations, but certainly those with a * above. AFAICT, the assertion is made only in sections 6.2 (end system processing), and 6.3 (intermediate system processing), which is insufficient IMO. >> 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. It would be useful to note that in the *'d places above where the limitations of the deployment would be stated. >>> 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. Agreed, but that doesn't mean these issues don't need to be addressed. > 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. I'm not sure I agree with that. If that's the case, then why bother with this document? I.e., if we're admitting that the Internet ignores the IETF, we can spend more time golfing ;-) >>> 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. > > The architecture is unchanged. I disagree - changing the endpoint IDs is a large change to the architecture - even if scoped to affect only MLS systems, and this needs to be addressed. > 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. I'm asking that the document explain how MLS systems' view of 793 and 1122 rules for TCP change as well. Others pointed out the potential need to "update" 793 regarding TCP changes; IMO this is needed for other network architecture docs as well. >> 3. this document needs a much more extensive treatment of how it changes >> the 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. Agreed. > Again, the Internet Architecture does not change. I disagree; for MLS nodes, there are implications to ICMP processing at least, and perhaps routing, that are not addressed. These are architectural changes. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmNfMACgkQE5f5cImnZrt/yQCgzqr6ulLrYnQuNn7JSGelx0le crcAoNhBQqz3Mw0RwfMQb3IifSjV9Wa9 =gWS8 -----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.