Subject: plans for updated policy schema after new IKE work?

From: Ricky Charlet <[email-masked]>
Date: Mon, 19 Nov 2001 15:46:32 -0800

Howdy,

	How would our new IKE/IKE-replacement drafts affect the IPsecPolicy
schema? Would we ratify these as is and do other schema docs later? Or
would we hold these current schema docs in check untill we find out how
the IKE protocol will look in the near future?

	Just asking... and I hope not to start any flame wars. I ask because as
one of the co-authors of the IPsec Configuration MIB doc, I would be
interested to know if we will have to work to move our doc into
compliance with a possible new policy schema.

-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." Benjamin Franklin

  Ricky Charlet   : SonicWall Inc.   : usa (510) 497-2103

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 21 Nov 2001 13:26:03 -0800

>>>>> On Mon, 19 Nov 2001 15:46:32 -0800, Ricky Charlet <[email-masked]> said:

Ricky> How would our new IKE/IKE-replacement drafts affect the
Ricky> IPsecPolicy schema? Would we ratify these as is and do other
Ricky> schema docs later? Or would we hold these current schema docs
Ricky> in check untill we find out how the IKE protocol will look in
Ricky> the near future?

Ricky> Just asking... and I hope not to start any flame wars. I ask
Ricky> because as one of the co-authors of the IPsec Configuration MIB
Ricky> doc, I would be interested to know if we will have to work to
Ricky> move our doc into compliance with a possible new policy schema.

Ricky,

I think that the data model and the MIB can both handle being modified
in a fairly minor way in order to reflect new IKE replacements,
assuming something drastic isn't done to the fundamental philosophy.
You probably haven't read either of the documents in quite a while,
but I suspect that they're already fairly well set up to simply add in
a new "son-of-ike" plugin set to deal with this.  This is simplifying
it a bit, of course, but in general I still think it's roughly true.

Plus, I doubt we can plan for the future to such a point that we can
start fixing things now before the new-IKE-authors have broken things ;-)

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 22 Nov 2001 09:18:21 +0100

Ricky,

Actually, Luis and us have given some thinking about the impact of the new 
IKE work. The -04 version of ICPM has even a change for it:
- a class SANegotiationAction: which should be the super class of all IKE & 
KINK & JFK of the world
- a class IKENegotiaionAction: which is a sub-class of SANegotiationAction 
for IKE (phases 1 & 2)

This should work for KINK at the time of writing -04. I still have to look 
into JFK but extension to JFK should be pretty easy as long as JFK respects 
RFC 2401. ICPM is mostly about SPD.

On another point of view, I really doubt that the IKEng will be implemented 
before months and, as I'm more from the deployment side of IPSec, I have 
strong doubts whether IPSec users will ever deploy the new IKE...

Just my 0.50 BEF (soon to be 0.01 EUR)

-eric