-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, Mike (et al.),
Michael StJohns wrote:
Hi Joe -
...
At 02:18 PM 10/2/2008, Joe Touch wrote:
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.
The issue isn't so much the network, but how the host views it and
deals with resources that might otherwise be in multiple sensitivity
domains.
Consider a multi-level host that runs at both SECRET and TOP SECRET.
Consider that it wants to run some protocol to send and receive data
from other hosts, some multi level, some single level SECRET and some
single level TOP SECRET.
A single level process at TOP SECRET does a passive open of the port
(call it 666) and waits for connections.
A second single level process at SECRET also attempts to do a passive
open to the same port - but gets blocked because the port resource is
being held by the TOP SECRET process. The SECRET process now has one bit
of information about the TOP SECRET part of the host. By grabbing and
releasing port resources, the TS process can signal data to processes at
lower security levels.
Understood. However, the lower security process can't know whether it's
the TS process doing this or some other reason (port blocked, e.g.); all
it knows is that it can't connect at the level it wants on
the port it wants.
...
The fix was to virtualize TCP so that there was a complete set of TCP
ports per distinct security domain.
I agree that this fixes your problem, but what it does is create a new
naming dimension to the entire Internet, and I don't think that this is
feasible.
Perhaps you'd prefer to black-hole the SYNs at the wrong security level,
which would still modify 793, but would not create the naming dimension
problem that concerns me...
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.
Not quite the point. If you have a single level process reserving a
TCP port, then the port has sensitivity level of the process. If you
have a multi-level process reserving a port then the port can have
one, some or all of the sensitivity levels of the process. Each
instantiation of a connection does have one and only one sensitivity
level.
I understand that this wasn't your point (or goal), but I'm claiming
it's the effect of your goal - and that it's untenable.
The changes don't have to happen on the entire internet, just those
hosts and routers that are CIPSO aware AND multi-level. If the host is
CIPSO aware (or for that matter IPSO aware), but not multi-level, it's
just looking for the specific label and doesn't have to deal with the
multiple virtual network cruft.
The changes need to happen for all RFCs that are affected by naming -
you're adding a dimension to naming by expecting different TCP
connections to occur where the only difference is security level. At
that point, the same has to happen for ICMP (so PMTUD works for each TCP
separately), which means you modify 1122. The same has to happen for
user apps, which now need to be able to connect to different sockets for
the same socket-pair - which modifies 1123. The same happens for 1812,
... That's the problem. Naming dimension extensions creep into the
architecture.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjlUFMACgkQE5f5cImnZrtk+gCghuu9R1AYnhNaaHZ/72Rfv4WC
EVQAoNV2aDQE3gYsl6+T9lWDbcqNbAaL
=KKNw
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf