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

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: