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

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
>
Follow-Ups: References: