[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
Scott
----- Original Message -----
From: "Michael Thomas" <mat@cisco.com>
To: "Scott Fanning" <sfanning@cisco.com>
Cc: "Michael Thomas" <mat@cisco.com>; <Internet-Drafts@ietf.org>;
<mailto:IETF-Announce:@cisco.com;; <ipsec@lists.tislabs.com>
Sent: Friday, July 27, 2001 7:52 AM
Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt
> Scott Fanning writes:
> > Er, you are right, but I don't see much movement on the ack'd notify
front.
> > Since changing IKE is not allowed, this seemed like the easiest route
to
> > move forward with. Also, acks could be lost as well, so 3b could happen
in
> > the ACK'd case as well. I do not claim that this solves every problem,
but I
> > think it is a simple solution that could be implemented in a short
amount of
> > time, with little interop issues.
>
> If there were a son-of-ike, would this be a potential change?
> It seems like all that his necessary is to have a bit which
> requires the peer to send a (potentially empty) notification
> in response.
>
> As far as the ACK lossage goes, there are two cases:
>
> 1) initiator loses the response from respondent
> 2) respondent loses ACK from initiator
>
> In case one, the initiator would obliged to retransmit
> its request since it didn't get a response. In case two,
> it's just a matter of knowing when to *really* shutdown
> the SA so that in-flight packets aren't lost, if it keeps
> the SA open at all while waiting for the ACK. In that
> case, a grace timer which expires in lieu of the ACK
> is probably sufficient since it's really just a courtesy.
> If respondent needs a fail safe method, it can, as well,
> send the delete notification as an initiator.
>
> Mike
>
> >
> > Scott
> > ----- Original Message -----
> > From: "Michael Thomas" <mat@cisco.com>
> > To: <Internet-Drafts@ietf.org>
> > Cc: <IETF-Announce:;>; <ipsec@lists.tislabs.com>
> > Sent: Friday, July 27, 2001 6:39 AM
> > Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt
> >
> >
> > >
> > > Er, wouldn't the more sensible thing to do here in
> > > general is to create a means of having a reliable
> > > Delete notification? This is what KINK does, and
> > > seems a lot more sensible/robust overall. I'll
> > > note that this still seems to have the packet loss
> > > problem described in section 3b.
> > >
> > > Mike
> > >
> > > Internet-Drafts@ietf.org writes:
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > > This draft is a work item of the IP Security Protocol Working
Group of
> > the IETF.
> > > >
> > > > Title : Responder Lifetime Notify Message for IKE
> > > > Author(s) : S. Fanning
> > > > Filename : draft-ietf-ipsec-ike-lifetime-00.txt
> > > > Pages : 5
> > > > Date : 26-Jul-01
> > > >
> > > > This document describes how the RESPONDER-LIFETIME notify message,
> > > > used within the ISAKMP DOI can be used to facilitate lifetime
> > > > negotiation and rekeying.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
> >
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with
the
> > username
> > > > "anonymous" and a password of your e-mail address. After logging
in,
> > > > type "cd internet-drafts" and then
> > > > "get draft-ietf-ipsec-ike-lifetime-00.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > > mailserv@ietf.org.
> > > > In the body type:
> > > > "FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt".
> > > >
> > > > NOTE: The mail server at ietf.org can return the document in
> > > > MIME-encoded form by using the "mpack" utility. To use this
> > > > feature, insert the command "ENCODING mime" before the "FILE"
> > > > command. To decode the response(s), you will need "munpack" or
> > > > a MIME-compliant mail reader. Different MIME-compliant mail
readers
> > > > exhibit different behavior, especially when dealing with
> > > > "multipart" MIME messages (i.e. documents which have been split
> > > > up into multiple messages), so check your local documentation on
> > > > how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > > Content-Type: text/plain
> > > > Content-ID: <20010726170632.I-D@ietf.org>
> > > >
> > > > ENCODING mime
> > > > FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt
> > > > Content-Type: text/plain
> > > > Content-ID: <20010726170632.I-D@ietf.org>
> >
References: