[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Traffic handling and key management "divide and coquer"
--- Sara Bitan <sarab@cs.Technion.AC.IL> wrote:
> I think that we are at a crucial point where we can make a change that will
> turn our work to more focused and efficient, and hopefully fruitful. I
> suggest we use a "divide and conquer" strategic.
> We should first of all separate IPsec transforms traffic handling (i.e. ESP
> and AH) and key management work to different WGs (if I understand right,
> this was raised by JI in the SAAG meeting).
I like focused work groups. IPsec WG should be focused on protocols
independent of IKE. IKE WG must be focused on delivering the key
maangement requirements of IPsec.
> This process is already happening as we speak - MSEC and KINK are working on
> key management protocols that create IPsec SAs, with different
> requirements. ESP and AH will still be used for traffic handling.
> If we will do the separation, we will soon be able to tell the industry that
> the work on the IPsec transforms is done, which I think will be a great
> advantage.
>
Yes.
> I think we should also allow for several key management protocols,
> preferably with one framework.
> This is the only way we will be able to cater for the requirements of "DSL
> geeks" as well as "billion mobile users" (quoting Jari's words).
>
> There are several actions that we need to take for this to happen:
> 1) Allow working groups other than IPsec to work on key management
> protocols, this way we could shut down the IPsec WG and keep on working on
> new key management protocols. As I said this is already happening.
> 2) Limit IPsec wg to only on the following IKE modifications : NAT
^^^^^^^^
I would prefer a name like "IKE WG", that is reflective of the
work the WG is focused on.
> traversal, SCTP support and re-keying. The new IKE version should be a minor
I would also suggest including the ability to specify IPsec SPD
in a flexible manner in Quick mode.
Above all, the new-IKE should be focused on servicing the IPsec
protocols. All of the modificications suggested (NAT traversal,
SCTP support, rekeying and support for IPsec SPD) share the
common theme of supporting IPsec deployment. Perhaps an RFC
focused on IPsec-IKE interaction would be immensely useful.
As it stands, IKE is taking center stage due to its complexity.
Issues with Ipsec are considered secondary compared to IKE.
The roles ought to be reversed. Ipsec deployment is the end goal
and as such the eventual focus should be shifted to Ipsec.
IKE should facilitate Ipsec, without taking the center stage
by itself with its complexity and inability to fully support
Ipsec in its deployment.
Thanks.
<... stuff deleted>
> Sara.
>
regards,
suresh
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
References: