[tcpm] [Fwd: Re: Secdir Review of draft-stjohns-sipso-05]

[Joe Touch <[e-mail]>]

FYI - discussion is happening over on the main list.

Joe

--- Begin Message ---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Steven M. Bellovin wrote:
> On Wed, 1 Oct 2008 22:12:17 -0400
> "Steven M. Bellovin" <[e-mail]> 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-----

--- End Message ---

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm