-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Wed, 1 Oct 2008 22:12:17 -0400 > "Steven M. Bellovin" <smb@xxxxxxxxxxxxxxx> 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, paraphrased): - 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. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL AicAn1kLwAQdQ087x9H32tbdVK26t1Hq =8u6k -----END PGP SIGNATURE----- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf