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

RE: Reliable delete notifies



Dan

I am also assuming that the new hash (or some equivalent) will be include to
ensure that all the payloads are covered ;-)

Also, and clarifications on the following would be nice..

1) Commit Bit: The usual confusion, but I am not sure how much more plain it
could be.
2) Notifies: Some of Scott Kellys notifies would be nice inclusions.
3) Acks on Notifies. I would like to see that a MUST, but the presence of
them would be a step forward.
4) Re-keying explained, and no wiggle room in it. Lots of interop problems
here. Linkage of Phase 1 / Phase 2 sas as an option would be nice.
5) Get rid of new group mode.
6) Allow for Authentication before DH.
7) Some accommodation for remote access would be nice, but might be out of
scope.
8) Recommendations of retries, timers, etc on IKE packets. This might avoid
the "15 times send a packet" method of reliability.
9) A well defined state-machine in the doc would be an added touch of class
as well.

I am sure there are more, but this is some of the things on my wish list.
Just my 2 cents. Maybe others would like to add to the wish list now, or
forever hold your piece.

Scott

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Friday, October 06, 2000 5:20 PM
> To: Jan Vilhuber
> Cc: Brian Swander; ipsec
> Subject: Re: Reliable delete notifies
>
>
>   I'm presently doing just that. The new draft will combine all three of
> the key management RFCs into one. This will give an opportunity to remove
> lots of the duplication, confusion, and conflicts that arose because of
> the 3 separate documents. I'm also planning on cutting out quite a bit of
> the optional things that are now referred to as "standards bloat". For
> instance, one of the public key authentication methods will be removed
> as will Aggressive Mode and most of the ISAKMP exchanges defined in
> RFC2408.
>
>   Dan.
>
> On Fri, 06 Oct 2000 16:35:11 PDT you wrote
> > Furthermore, can someone resurrect son-of-ike? Dan? Any word on
> this? If not
> > you, should someone else take this?
> >
> > There's good stuff there that we should get into the next rev
> of ike. This
> > stuff is important to increase IKE robustness and interoperability.
> >
> > jan
> >
> >
> >
> >
> > On Fri, 6 Oct 2000, Brian Swander wrote:
> >
> > > Reliable deletes are basically essential for decent interop
> of IKE, and
> > > most people I talked to at the last bakeoff agree with me.  However, I
> > > am concerned that the draft that mentioned them (son-of-ike) has not
> > > only not progressed, but has vanished.
> > >
> > > That is problem 1.  Equally important is how reliable notifies will
> > > work.  One of the brilliant aspects of the draft (i
> erroneously thought)
> > > was that it also addressed the backwards compatibility problem.  I had
> > > initially interpreted the draft to say that reliable notifies were
> > > exactly like normal notifies, except that the payload
> contained an extra
> > > Nonce field for liveness checking of the Ack.  I felt this brilliant,
> > > since down level clients who didn't support the reliable
> notify wouldn't
> > > send a response, ignore the nonce, but otherwise process the message.
> > > The cost is a few extra retransmissions, which also serve to
> insure that
> > > the peer gets the message anyway.
> > >
> > > It was pointed out to me, however, that there is a new exchange number
> > > for reliable notifies.  Doing this breaks all the beautiful backwards
> > > compatibility.  Of course, we can do the standard silly IKE thing of
> > > negotiating reliable delete functionality with the vendor ID
> payload, or
> > > sending double the notifies, once with the standard number, and once
> > > with the new one.  Both of these methods seem much less clean
> then just
> > > having a single info exchange ID.
> > >
> > > Can someone justify the choice of changing the exchange type, and also
> > > comment on if there are any plans to actually advance this necessary
> > > functionality beyond the word-of-mouth stage.
> > >
> > > bs
> > >
> >
> >  --
> > Jan Vilhuber
> vilhuber@cisco.com
> > Cisco Systems, San Jose
> (408) 527-0847
> >
>



References: