[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Agenda for the Minneapolis meeting
One thing Scott said that is important is to remove ambiguity. Sometimes it
is misguided to associate brevity with simpicity. ISAKMP is very long and
convoluted, but at least it is unambiguous enough to prevent
interoperability problems.
How many times have you seen interoperability problem due to badly formed
payloads on the wire as opposed to problems with rekeying or load sharing or
cert usage or all those other things that were mostly left out of IKE.
Some other wants:
- 4 message non-encyrpting mode (i.e. base mode)
- Dave Mason's 4 message QM instead of the commit bit fiasco.
- message id as counter for replay protection
- deprecate PFS (I wish)
- specify placement of the cert request within the phase 1 exchange
I still think removing the distinction between IKE and ISAKMP is very
dangerous. We are only now beginning to see the benefits of separating the
two. With work in progress on areas like MSEC, SMPLS, Tero's KINK draft,
Jari's MAP DOI, I think we would be insane to merge the protocol layers at
this point in the game
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 Scott Fanning
> Sent: Thursday, March 15, 2001 11:13 AM
> To: Mike_Borella@3com.com; Dan Harkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Agenda for the Minneapolis meeting
>
>
> My even cheaper 2 cents :-)
>
> - Incorporate the spirit of the revised hash.
> - Clarify rekeying. When to use the new SAs vs Old ones etc.
> - Eliminate KB lifetimes.
> - Clearly define certificate handling. Remove ambiguities.
> Things like some
> vendors will not sent certs (even if negotiated) unless
> specifically asked.
> I think this is the right behavour as, with multiple root
> support, it would
> be nice to know what chain of trust is applicable to the peer-to-peer
> communication. Sending all of the certs on a head end route
> would no doubt
> be very expensive.
> - Any chance of Going with base mode as a compromise between
> AG and MM?
> - Better defined Notify messages and actions on receipt of them. Scott
> Kellys work is pretty good in this direction.
> - Remove new group mode.
>
> Regards
> Scott
>
>
> ----- Original Message -----
> From: <Mike_Borella@3com.com>
> To: "Dan Harkins" <dharkins@cips.nokia.COM>
> Cc: "Scott Fanning" <sfanning@cisco.com>; <ipsec@lists.tislabs.com>
> Sent: Wednesday, March 14, 2001 7:01 PM
> Subject: Re: Agenda for the Minneapolis meeting
>
>
> >
> >
> >
> > FWIW, all of the below are cool ideas. My very cheap 2 cents:
> >
> > o Clarify the ephemerality of the IKE source port
> > o Words on IKE over SCTP
> >
> > Mike
> >
> >
> >
> >
> >
> > Dan Harkins <dharkins@cips.nokia.COM> on 03/14/2001 06:50:10 PM
> >
> > Sent by: Dan Harkins <dharkins@cips.nokia.COM>
> >
> >
> > To: "Scott Fanning" <sfanning@cisco.com>
> > cc: ipsec@lists.tislabs.com (Mike Borella/MW/US/3Com)
> > Subject: Re: Agenda for the Minneapolis meeting
> >
> >
> >
> > I don't have any powerpoint slides or anything like that
> but what I'm
> > going to talk about is:
> >
> > *) what is this-- RFC2407+RFC2408+RFC2409 = new draft
> > *) why do this?
> > - we have an overly complex way to get SAs for IPsec.
> > - a general feeling of "I don't like IKE", published
> > criticism, and general fear of an overly complex
> > security protocol.
> > - it's not so bad that we need to throw it all out
> > and start over again-- there are nice features to keep.
> > *) why do we have what we have?
> > - original idea of a generic transport (ISAKMP)
> which could
> > have multiple key exchanges defined on it, a generic key
> > exchange which can establish "security associations" for
> > multiple services, and a service definition for IPsec.
> > - these layers created ambiguity.
> > - key management war resulted in a please all people at all
> > costs mentality that caused an explosion of options.
> > *) what does it mean to combine these three RFCs?
> > - no "layer violations" when defining things
> (like the commit
> > bit: it's from a header defined in RFC2408 used
> in an exchange
> > defined in RFC2409 because of an aspect of the
> service defined
> > in RFC2407) so we gain in clarity.
> > - we lose the generic transport and generic key exchange and
> > gain a key exchange and security association establishment
> > protocol for IPsec.
> > - some things, like Aggressive Mode and New Group Mode, get
> > left behind for possible redefinition and
> advancement in an
> > independent draft.
> > - advances in the state-of-the-art should depricate
> some of the
> > mandatory options-- DES, group1-- and that can happen in a
> > rewrite.
> > - many of the suggestions for protocol improvement can be
> > incorporated. How many and which ones is up to the working
> > group.
> >
> > I'm glad this is eliciting interest. I've brought the
> subject up on the
> > list in the past and there didn't seem to be much interest. Please
> comment!
> > There has also been an offline discussion about not caling
> it IKE anymore
> > since it won't really be IKE and any comments on that idea
> are solicited
> > as well.
> >
> > Dan.
> >
> > On Wed, 14 Mar 2001 15:30:07 PST you wrote
> > > For those of us not able to attend Minneapolis, is there
> any info on
> "Son of
> > > IKE" that we can comment on via this list before the meeting?
> > >
> > > Thanks
> > > Scott
> > > ----- Original Message -----
> > > From: <tytso@mit.edu>
> > > To: <ipsec@lists.tislabs.com>
> > > Sent: Wednesday, March 14, 2001 3:07 PM
> > > Subject: Agenda for the Minneapolis meeting
> > >
> > >
> > > > Hi all,
> > > >
> > > > My apologies for not prepared an agenda earlier; both
> Barbara and I
> have
> > > > been rather swamped at work lately.....
> > > >
> > > > This agenda is a draft; if you would like to request
> some time at the
> > > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many
> thanks.
> > > >
> > > > - Ted
> > > >
> > > > A. D. Keromytis
> > > >
> > > > On the Use of SCTP with IPsec
> > > >
> > > > Dan Harkins
> > > >
> > > > "Son of Ike"
> > > >
> > > > IPSEC MIB documents
> > > >
> > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt
> > > > draft-ietf-ipsec-ike-monitor-mib-02.txt
> > > > draft-ietf-ipsec-monitor-mib-04.txt
> > > >
> > > > Jari Arkko -- IPSEC and IPV6
> > > >
> > > > Effects on ICMPv6 on IKE and IPsec Policies
> > > > Manual SA Configuration for IPv6 Link Local Messages
> > > >
> > > > Tissa Senevirathne
> > > >
> > > >
> http://search.ietf.org/internet-drafts/draft-> tsenevir-smpls-doi-00.txt
> > > >
> > > > IPSEC and NAT
> > > >
> > > > Markus Stenberg <mstenber@ssh.com>
> > > >
> > > > draft-stenberg-ipsec-nat-traversal-02
> > > >
> > > > William Dixon
> > > >
> > > > draft-huttunen-ipsec-esp-in-udp-01
> > > >
> > > >
> > >
> >
> >
> >
> >
>
Follow-Ups:
References: