-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael StJohns wrote:
At 07:01 PM 10/2/2008, Joe Touch wrote:
...
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.
Naming? Not really. Addressing maybe - but that's - as I said before
- pretty local to only those hosts that implement MLS.
In TCP, endpoint names are composed of the 4-tuple (localIP, remoteIP,
localPort, remotePort). You'd first need to extend that to include MLS
as part of the endpoint name.
I'm not sure how this works with IPsec, since transport mode wants to
filter on ports, and you now can have only one transport mode
association for all MLS levels for a given port.
For ICMP to work, you need to care about intermediate devices sending
back enough of the IP and TCP header - including the MLS option - to
demux the info back to the correct TCP. Since TCP connections are
currently defined by the 4-tuple, you also need to extend ICMP
processing to send the ICMP payload to the right TCP connection.
This means, at least, extending IPsec, TCP (UDP, SCTP, RTP, ...), and
ICMP processing on the end host to support your extending notion of an
endpoint name.
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...
Define "wrong security level" - both the attacker and victim are operating
at their own security levels, its just the resource interactions that lead
to the covert channel.
"wrong security level" means that when segment with a SYN set arrives to
a TCB set for a given level, the segment's level must match that of the
TCB. That's as defined in 793.
Which SYN's - (need an exact filter definition here please) would you
black hole, and how would that solve anything?
I'm focusing on the behavior of TCP on the wire (and explained the SYN
issue above); there is also the issue of port binding, which is different.
The port issue is really an OS problem. IMO, a process at level A that
wants to bind to port X might silently return a "sure, you're bound"
response if the port is bound to a different process at a different
level. The OS should accept the connection only for a specific process,
though - i.e., the first one to bind to the port, or the highest one to
bind to the port.
The point I'm making is that there seems like there should be a way to
prevent the covert channel without mucking up TCP's definition of what
an endpoint is.
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjla8cACgkQE5f5cImnZrtL7QCfcA/xQe1nJa0UaXd6+GNs3m6c
KQkAoJIQfEHevT0IDim5iWREuJ+Dui/Y
=Fwxy
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf