[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
API issues (was Re: IPsec and TCP )
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Derek" == Derek Palma <dpalma@netcom.com> writes:
Derek> I also ran into the same problem (which started this
Derek> thread). When exactly do you think keying should start?
Derek> If you defer until the user initiates a connection but
Derek> before TCP starts, you must obtain control somewhere in the
Derek> application layer.
It seems to me that there are three possibilities:
1. the application requested crypto with a setsockopt()
2. the system been told to communicate securely to this
endpoint only.
3. there is a tunnel to this endpoint.
For case #1, it seems one should do the key exchange during the
setsockopt() call. I.e. do not return until the SA's are in place, or
return an error. This has the problem that setsockopt() is not
something you can normally do asynchronously. If some operation is
going take some some time, you might want to be able to select() on it.
For case #2, there are three subcases:
+ a common SA is desired/permitted. It should be setup
when the system is told to do this.
+ a common SA is setup, but the application wants private
keying. The application will arrange this, this is like #1.
+ the policy is for private keying for each connection. I
do not know how to deal with this one.
For case #3, the SA is setup when the tunnel is created.
In all cases, if it takes a long time to negotiate the tunnel, then
it must be because the network is congested and/or remote node is
slow. In either case, it is appropriate for TCP's back off to be
trigged.
:!mcr!: | Network security consulting and
Michael Richardson | contract programming
WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQBVAwUBMrwHatTTll4efmtZAQHZvQH/WQSY48fmYJe/ivOzvvVFFKY1R3+cpZ7h
xa7yVMq60iGc9V0ZClL+nAFtrEvO+WGqqtDb1Hq+7kTV5yLTHAKkTQ==
=2uYT
-----END PGP SIGNATURE-----
Follow-Ups:
References: