[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bundle or not in negotiation
> From: Daniel Harkins <dharkins@dharkins-ss20.cisco.com>
> Where does the requirement to use PFKEY come from? Plumbing from IPSec
> to IKE and back is not in the IPSec or IKE protocol definitions.
> We shouldn't dictate how two peers communicate by what they do on
> the backend.
I'm not requiring PFKEY from IKE, but I still assume the IPSEC
architecture document holds, and the key management requirements
stated by it can be realised with PFKEY.
> If your mulltiple ACQUIRE messages all refer to the same traffic and
> peer then it makes sense to negotiate them all at once. When you do
> they are treated as a bundle.
Negotiating them together is a sensible optimization. Why does IKE
need to know about bundles (as defined in IPSEC architecture)?
What does it use this info for?
> But if you do negotiate things seperately then what do you do with
> the packets that are queued up after the 1st negotiation is finish
> but before the 2nd is finished?
A brutal solution is: don't queue up anything, drop all until all
required SA's are present. Again, queuing packets for a while and
waiting is yet another optimization. Not requirement in the "virtual
reference implementation".
> Or do you wait until all negotiations are finished? If the latter
> then what's the point of doing them separate.
Simplicity of implementation. Divide and conquer principle.
> Again, PFKEY is not a requirement. But this illustrates the problem PFKEY
> has since it defines its own magic number space instead of multiplexing off
> a DOI and using what IANA is already defining.
Actually I agree somewhat on above, PFKEY doesn't need to care what
actual algorithm numbers are. I have totally ignored the symbols
SADB_AALG_* and SADB_EALG_*. Instead, IPSEC has a configuration
mapping from algorithm number to algorithm implementation function,
and could use any numbers as long as both ends use the same to mean
same algorithm.
> There is no reason why IKE has to do magic number translation and
> there is no reason why IKE has to know that if the DOI is 3 and
> attribute 8 has a value of 2 that it's referring to HMAC-TIGER for
> RSVP (I'm making those numbers up for illustration).
Exactly. However, someone needs to tell IPSEC enginge that '2' as
authentication algorithm means HMAC-TIGER (= my configuration file),
but I agree, IKE or PFKEY should not need to care about exact number
values.
--
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
References: