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

RE: Traffic handling and key management "divide and coquer"



I completely agree. I think some people have been much too quick too suggest
dumping the entire framework we have developed over several years. Can we
finally put what happened to Skip & Photuris behind us and stop
schizophrenically shedding protocols?

The IPsec WG has never been able to agree on requirements for anything. It
seems idealistic and naive to believe that we could start over with a brand
new KMP and acheive a different result. Like it or not, IKE was the
preordained result of a design by commitee,a political process. The
alternative to a committee process is a fascist process. Take your pick. I
personally don't like either committees or facism, but I'll take committees
any day of the week.

Listen to the arguments we've heard on the list recently: Let's "simplify"
IKE by reducing the number of messages, making the exchange asymmetrical,
optionally adding a cookie exchange when the responder is under DoS,
optionally piggybacking phase 2 on phase 1, optionally reducing the message
count by allowing optimistic negotiation, optionally telling the initiator
to retry the negotiation with different groups, changing phase 1 so it can't
be used transparently in MSec, changing phase 2 so it can't be easily
leveraged for KINK.

Instead of spending another 2 years arguing and developing a new protocol
that inevitably falls into the same old traps of optimization vs. simplicity
vs. features, I suggest that we do basically what Sara suggests. To steal a
comment from Ferguson/Schneier, ISAKMP is a framework for creating security
protocols; the problem with IKE is that it also seems like a framework for
creating security protocols.

Let's have one protocol which is based on IKE MM/QM + improveike for VPN
users, and a separate protocol (optimized for low-bandwidth applications)
for things like ISCSI. Make them more specific than IKE is right now, but
design them on top of ISAKMP so that those of us who need to write all of
IKE and MSec and KINK and MPLS-SEC and MAP-DOI and whatever other esoteric
usage of IPsec comes along, can at least leverage some of our code.

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sara Bitan
> Sent: Tuesday, August 14, 2001 9:46 AM
> To: ipsec@lists.tislabs.com
> Subject: Traffic handling and key management "divide and coquer"
>
>
> 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).
> 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.
>
> 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
> traversal, SCTP support and re-keying. The new IKE version
> should be a minor
> version including only minor fixes (as outlined in the new suggested
> charter).
> 3) Re-assure ourselves that the interface between transforms and key
> management is clearly defined, and general enough to allow
> for the addition
> of new key management protocols, without having to change the
> transforms.
> 4) Have a framework protocol for key management - I think it
> should be based
> on ISAKMP. There is no need to re-invent transforms and
> proposals syntax for
> each new key management protocol.
> 5) Have different requirements for different key management
> protocols. With
> one common requirement - they should all create IPsec SAs.
> This way we could
> have one requirements document include Identity protection,
> and allow for a
> larger number of messages, and another that has no Identity Protection
> requirement, and requires a small number of message. We can
> also have one or
> several WGs in charge of the key management protocols.
>
>  Sara.
>



Follow-Ups: References: