Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt

"Scott Fanning" <sfanning@cisco.com> Fri, 27 July 2001 17:25 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RHP9s26935; Fri, 27 Jul 2001 10:25:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13827 Fri, 27 Jul 2001 12:33:52 -0400 (EDT)
Message-ID: <007201c116ba$6ef06160$872745ab@cisco.com>
From: Scott Fanning <sfanning@cisco.com>
To: "Mason, David" <David_Mason@nai.com>, Michael Thomas <mat@cisco.com>
Cc: ipsec@lists.tislabs.com
References: <8894CA1F87A5D411BD24009027EE7838128218@ROC-76-204.nai.com>
Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt
Date: Fri, 27 Jul 2001 09:37:31 -0700
Organization: Cisco Systems
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Thanks. I am hoping that all of us can pull together to do the son-of-ike
based on all the lessons learned. I very much agree that the revised hash is
the way to go, and needs to be built into the next ike revision. I would
like hybrid as well to cover the remote access angle, but thats another
story :-) Does anybody know the current status of son-of-ike? I missed the
last IETF, and I had heard that there was a presentation done on it. Is
there anything on the agenda for an update?

Scott
----- Original Message -----
From: "Mason, David" <David_Mason@nai.com>
To: "'Scott Fanning'" <sfanning@cisco.com>; "Michael Thomas" <mat@cisco.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Friday, July 27, 2001 9:21 AM
Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt


> > One of my motivations of this draft was to "gently" push for a
son-of-ike.
> I
> > would love to see the ACK'd notify messages in Son-of-ike or maybe
> > recognition that this is a stateful protocol that either requires
> connection
> > based transport, or better defined robustness in the draft. I still
think
> > that, until that day comes, this is still a useful proposal. Maybe this
> > could be in the son-of-ike as well.
>
> Hopefully son-of-ike will incorporate
> draft-ietf-ipsec-ike-hash-revised-02.txt
> in which case phase 1 responder lifetimes can be protected within the
phase
> 1
> exchange.  Although this info would then be exposed in Aggressive Mode (or
> the
> AM replacement if there is one in son-of-ike), it will at least be
protected
> from modification under the revised hash.
>
> I have seen many implementations that already send IKE responder
lifetimes.
> In RFC2407 when it mentioned using the cookies for the SPI that's what I
> thought it was referring to (IKE not IPsec responder-lifetime).
>
> In the spirit of be strict in what you send and forgiving in what you'll
> accept it should be noted that the receiver of IKE responder lifetimes
> SHOULD accept a Notify DOI field of IPSEC (1) as well as IKE (0).
>
> -dave