ietf
[Top] [All Lists]

Re: Secdir Review of draft-stjohns-sipso-05

2008-10-02 15:39:12
I totally agree with Mike. If you've never dealt with a multi-level security (MLS) system, let's just say they are non-trivial, and this issue with TCP ports is only one part of the overall system. Just the act of labeling the IP packets effectively creates multiple virtual networks, and the place where they clash is in the MLS host. As Mike said, those that aren't MLS aware don't have to do anything different. But explicitly calling this out for MLS hosts, as this draft does, seems to me to be perfectly reasonable.

                        -David Borman

On Oct 2, 2008, at 1:57 PM, Michael StJohns wrote:

Hi Joe -

A quick disclaimer - although I was complicit in allowing this draft to be resurrected from 1992, I have had very little to do with it on this cycle.


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.

In 1987 I used a rough analog of the old 1822 protocol using TCP ports to build a fairly fast covert channel between two processes at different security levels on the same host.

The fix was to virtualize TCP so that there was a complete set of TCP ports per distinct security domain.

You could try doing this by writing the processes as multi-level, but that means you can't use off the shelf code for things like a mail server that only wants to handle mail of a specific security level.

Mostly, this only applies to protocols just above IP which have distinguishable host resources. In other words, TCP, UDP and their ilk.



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.

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.


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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf