Alan Stern <stern,AT,rowland,DOT,harvard,DOT,edu>|
Re: CIPE-Win32: communication breakdown|
Damion Wilson <dwilson,AT,ibl,DOT,bm>|
Thu, 12 Jun 2003 13:11:19 -0300|
And that's what I do in CIPE-Win32 (I read the same section several times).
If you read Christof's message of June 6, he asserts that there is a key
negotiation problem over less reliable links due to CIPE invalidating the
key before the NK_ACK and CIPE-Win32 continuing to use the key until
I think that's right. When in doubt, both sides should use the static key,
which they do.
On Thursday 12 June 2003 12:13 pm, you wrote:
> On Mon, 9 Jun 2003, Damion Wilson wrote:
> > Christof is saying that the peer starts using the new key without the
> > ACK. I'm the one saying that CIPE-Win32 doesn't use its newly generated
> > key until the ACK is sent back. Who are you agreeing with ?
> > DKW
> Sorry, I think we got a little confused over which CIPE is doing what. If
> it helps, here is a direct quote from cipe.texinfo:
> The key negotiation procedure normally runs as follows: The sender
> sends a NK_IND with the new key, then invalidates its own sending key.
> Upon receipt of NK_IND, the receiver starts using this key as its
> receiving key and sends a NK_ACK. When the sender receives NK_ACK, it
> starts using the new key as its sending key. If either of NK_IND or
> NK_ACK is lost in transmission, no new key will be used. The sender
> should send a new NK_IND (with new key) if no matching NK_ACK is
> received within a reasonable amount of time (current specification: 10
> The unmentioned implication is that during the period when the old and new
> sending keys are both invalid, the sender falls back on the static key.
> That should clear things up.
> Alan Stern
> > On Friday 06 June 2003 04:31 pm, Alan Stern wrote:
> > > On Fri, 6 Jun 2003, Damion K. Wilson wrote:
> > > > I don't think that this approach is wrong, and it's intentionally
> > > > written that way. If A says to B: "I'm changing my key, here it is"
> > > > and B never says: "I got it, go ahead" then there has been no
> > > > successful key exchange so both A and B must try again.
> > > >
> > > > I didn't know that CIPE invalidates the key before receipt of the
> > > > NK_IND has been acknowledged by the peer. It the NK_ACK wasn't
> > > > necessary, why have it at all ?
> > > >
> > > > Olaf, if you're listening, do you have any guidance ?
> > >
> > > My memory may be a little rusty, but I think Christof was right. The
> > > reason for the NK_ACK message is that CIPE won't start to use the new
> > > key until the NK_ACK is received. Until then it will fall back on the
> > > static key.
> > >
> > > At least, that's what the documentation says. Maybe the implementation
> > > is different.
> > >
> > > Alan Stern