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

Re: Bundle or not in negotiation

On Wed, 18 Nov 1998 20:31:04 +0200 you wrote
> I guess I am getting repetious and perhaps a pain in * for some, but I
> still make this question once more, prompted by following
> 
> > From: Tim Jenkins <tjenkins@TimeStep.com>
> 
> > As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between
> > two peers, and the ESP part expires first, it is likely that the entire
> > SA will be torn down. I stated in the document that the assumption is
> > that the SA bundle lives only as long as the shortest living service
> > in the bundle.
> 
> Where does the requirement come that a bundle IPCOMP+ESP+AH needs to
> be negotiated as a bunch? Assuming IPSEC architecture and PFKEYv2
> interface to kernel (and ignoring the IPCOMP for a moment), the key
> management gets TWO independent and unordered ACQUIRE messages (ESP
> and AH), there is no need to connect them together, they can be
> negotiated independentely, and they may even have a different
> lifetimes.

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 don't see any problems with this freedom. A while back I posted few
> scenarios of how I see things to happen in negotiation. I hope that
> someone could give me an example that actually requires treating them
> as clump in negotiation phase.

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.

Of course you don't have to do that. You can do multiple negotiations
and be inefficient if you want. 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? 

If your plumbing can't handle a set of requirements and can only dole
things out one at a time and your policy says "AH AND ESP for traffic
from foo to bar with frobnitz as the peer" then you'll do an AH negotiation
with frobnitz and then a separate ESP negotiation with frobnitz. When the
first is finished whaddya do? Send packets with AH but not ESP? Or do
you wait until all negotiations are finished? If the latter then what's
the point of doing them separate. I'm missing something.

> The appliation order of IPCOM+ESP+AH is defined by the policy, which
> *must* specify same order on both sides. The order is
> non-negotiable.
> 
> IPCOMP is a problematic. It is not included in the PFKEYv2, there is
> no way of IPSEC kernel to request IPCOMP in ACQUIRE, even if the
> policy wanted it. I see only two tracks of solving this:

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. Oh well. I don't think this
design decision should influence how IKE or IPSec operate. 

>  1) Make new SA type for IPCOMP => then you could negotiate IPCOMP
>     independently same way as AH and ESP
> 
>  2) Make IPCOMP a new algorithm in SA => this would need a change in
>     PFKEYv2 message format, as a slot would have to alloated for the
>     compression algorithm (at similar to 'auth' and 'encrypt').
>
> Maybe there are other ways, but those above are the first that come to
> mind. 

Another way would be for PFKEY to include a DOI identifier and allow for
negotiation of IANA defined magic numbers. 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). It
just offers them and accepts or rejects them based on local policy. Then
when another DOI, for OSPF or RIP or whatever, is defined, and a new set
of magic numbers is assigned by IANA you don't need to change key management 
to do magic number translation, it just works. The problem you're having
with PCP will reappear when IKE is used to negotiate security parameters
for any other service.

But that's a PFKEY problem and not an IPSec problem or an IKE problem.
Those of us that aren't using PFKEY do not have the problem you describe.

  Dan.
Follow-Ups: References: