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