-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steven M. Bellovin wrote:
On Wed, 1 Oct 2008 22:12:17 -0400
"Steven M. Bellovin" <smb(_at_)cs(_dot_)columbia(_dot_)edu> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf