[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Agenda for the Minneapolis meeting
My 2 cents: Clarifications of the ID payloads and their use in phase I and
phase II exchanges would be great.
Claudio.
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@cips.nokia.COM]
> Sent: Wednesday, March 14, 2001 7:50 PM
> To: Scott Fanning
> Cc: ipsec@lists.tislabs.com
> 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
> >
> >
>