[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: