-----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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf