[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Policy question

Consider that I have a machine that has no specified security preferences.
That is, w/o additional per-socket tweaking, outbound traffic goes out in the
clear and that inbound traffic is cheerfully accepted in the clear.

Now consider an encrypted TCP SYN that is received by this machine.  For the
time being, assume the inbound SA is in place (I'll touch more on this
later).  Given the lack of policy constraints I can do several things:


	1.) Send back the SYN/ACK in the clear.  This certainly obeys the "no
	    specified security preferences" policy, but it has the
	    disadvantages of sending cleartext in response to ciphertext
	    (possibly aiding an eavesdropping adversary), and that cleartext
	    reply may be dropped by the sender for failing the sender's
	    policy.

	2.) Drop the SYN.  This has the advantage of not providing an
	    adversary any clues beyond "encrypted packets get rejected", and
	    it will cause the sender's TCP to time out.  This also means bits
	    do not get transferred.

	3.) Send the SYN/ACK using the same levels of security as the inbound
	    SYN.  This will keep the sender happy, foil the eavesdropper, and
	    move bits.  This also means possibly making TCP more aware of
	    IPsec state.

I deliberately picked TCP as the example because connections are "latched"
into place, and because UDP endpoints are connectionless, and policy may be
different between different destination ports or addresses.

One other thing to consider, which you may have picked up earlier, is that it
is possible to have the IKE daemon on this machine deliberately reject all
requests for negotiating secure services in this case.  (This means the SYN
would never arrive, as the IKE negotiation would fail.)  This is okay, but if
only manual keying is being used, you can't have that sort of access control.

So what should one do given the above situation?  I suspect my alternatives
were ordered least-to-most preferable.  I'd appreciate feedback from the list
on this.

Thanks,
Dan
Follow-Ups: