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

RE: Phase 1 Re-keying Implementation Identification





---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: November 18, 1999 1:28 AM
> To: Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Phase 1 Re-keying Implementation Identification 
> 
> 
> On Wed, 17 Nov 1999 19:52:09 EST you wrote
> > 

...

> 
> This document does not prevent packet loss-- one of its 
> stated goals-- 
> because it requires the responder to delete all phase 2 SAs 
> created with 
> the "old" phase 1 SA upon a phase 1 "rekey". That means that 
> packets will
> be dropped while a Quick Mode is done on the new IKE SA.

What are you talking about? Where does it say that?

Once the phase 2 SAs are up, they get re-keyed independently
of phase 1. The only that might change is which phase 1 SA was
used to protect the quick mode.

>From the document:

==>
   Therefore, the rules for phase 1 re-keying are:

       Initial Phase 1 Negotiation:
           -responder deletes any pre-existing phase 1 SA with the
            peer
           -use Initial Contact notification
           -responder deletes all phase 2 SAs with the peer

       Phase 1 Expires:
           -delete notification may be sent

       New Phase 1 is Negotiated
           -responder deletes any pre-existing phase 1 SA with the
            peer
           -no Initial Contact notification; phase 2 SAs are kept
                                             ^^^^^^^^^^^^^^^^^^^^
           -if attempt fails, all other SAs are also deleted (no
            delete notification is used, since there is no valid SA)
<==

If somewhere else it suggests that the phase 2 SAs have to go away
when the phase 1 SA expires and there exists a new phase 1, I need
to know where that is to clean it up.

> 
> It also causes more problems that it does not attempt to solve. The 
> description of the "Continuous Channel Implementations" says:
> 
>   "Note that this automatic re-keying of phase 1 SAs means that SAs
>    could live independent of traffic, since re-keying of both phase 1
>    and phase 2 SAs takes place with no traffic triggers (if 
> they expire
>    by time). In other words, SAs that are no longer necessary 
> may never
>    disappear.
> 
>    This suggests that a traffic monitoring capability should 
> be part of
>    implementations that need to delete idle or unused SAs. As such, it
>    is not given further consideration, since it is beyond the scope of
>    this document."
> 
> SAs that never disappear?! 

That was badly phrased. It should have said:

    In other words, SAs that are no longer necessary may continue
    to be re-keyed indefinitely.

But I think you knew that.

Further, it doesn't case this problem. This problem could exist
with any phase 1 re-keying model except for the one you seemed
to think that it proposed when you thought it said that the
phase 2 SAs should go away.

> 
> > There are many reasons for wanting a continuous channel 
> besides for sending
> > deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry),
> > negotiating different phase 2 SAs with the same endpoints 
> (for whatever
> > conceivable reason), heartbeat/keep-alive protocols, legacy 
> authentication
> > protocols (e.g. periodic reauthentication), configuration 
> protocols (e.g.
> > private address renewal), the ability to carry information 
> across a phase 1
> > rekey, lifetime notifies or other informational messages, 
> other protocols
> > that we haven't even imagined yet.
> 
> IKE is a session establishment and key exchange protocol, it is not a 
> catch-all transport for "other protocols that we haven't even 
> imagined yet."
> This may be part of the problem: you have a hammer and now 
> everything looks
> like a nail.
> 

So, you're saying that a phase 1 SA should be used to protect
key exchanges only. So, we should outlaw the New Group exchange
and no other exchanges?

Andrew wasn't suggesting that IKE be used as transport. He's
suggesting that the protection offered by the phase 1 SA
can be used for other things.

New Group Mode is an example of this, as is Configuration-Exchange.

IKE daemon heartbeats is a potential example of this as well.

...

> 
> It seems to me that you can't just say "if you don't want to 
> do it you don't
> have to". Everybody will have to implement some portion of 
> this Rube Goldberg
> machine just to remain interoperable.

I don't agree with this. If this was correct, it would mean
the continuous channel model violates the protocol. Can you
point out where it violates the protocol?

The resources argument is valid, but that means it's related to
implementation and application.

I think we need to agree to disagree on this one, if that's
possible. And similarly for the complexity.

> 
>   Dan.
> 

Tim


Follow-Ups: