RE: dynamic ports vs. rekeying

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> Is this still an issue in ikev2? Quick mode is no longer 3 messages,
> so the responder can immediately install all SA's and the initiator
> can start sending when he receives the reply...

It's an issue because of this scenario:

Alice and Bob have an SA for TCP connection #1: ports 123-12345

Later on, Alice wants to add a selector for TCP connection #2: ports
234-23456

She sends Create_Child_SA1 for an SA that covers both connections, and Bob
replies with Create_Child_SA2, but the packet gets dropped. Now Bob will
start sending traffic for connection #1 on the new SA, which Alice hasn't
installed yet. A phase 2 message to add selectors doesn't have that problem.

I suppose you could work around this problem to a certain extent by having
Alice do "Initiator Pre-Setup" (installing the new SA before the negotiation
is complete). But this is kind of kludgy, and it certainly doesn't work with
PFS (to open up that can of worms again).

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> Sent: Friday, April 05, 2002 7:14 PM
> To: Andrew Krywaniuk
> Cc: sommerfeld@east.sun.com; 'Paul Hoffman / VPNC'; 'Tero Kivinen';
> ipsec@lists.tislabs.com
> Subject: Re: dynamic ports vs. rekeying
>
>
> On 5 Apr 2002, Andrew Krywaniuk wrote:
>
> > I think dynamic selectors are different from rekeying. Not only does
> > updating the selectors of the existing SA save bits on the
> wire, but from a
> > robustness point of view, it means that to any
> synchronization errors
> > between the peers will only affect the new traffic.
> >
> > Imagine there is a race condition between the QM3 (or
> Create_Child_Sa2) and
> > the data traffic. The most reliable thing to do is to send
> the old traffic
> > on the old SA for a short while and send the new traffic on
> the new SA
> > (since the selectors won't match the old SA). Wouldn't it
> be easier to send
> > send all traffic on the new SA automatically because the
> new SA is the old
> > SA? If the selectors haven't been updated yet then new
> traffic will be
> > dropped for a short while.
> >
> > On the subject of rekeying, I agree that using the old
> phase 1s until they
> > expired (as specified in draft-jenkins) didn't work, but
> the immediate
> > switch-over in draft-specncer is too hasty. I recommend that an
> > implementation should continue to use its old SA for a
> short time (e.g. 30
> > seconds) after the new one is negotiated to account for any
> lost packets. It
> > should also wait a short time after that before deleting the old SA.
> >
>
> Is this still an issue in ikev2? Quick mode is no longer 3 messages,
> so the responder can immediately install all SA's and the initiator
> can start sending when he receives the reply...
>
> jan
>
>
> > -------------------------------------------
> > There are no rules, only regulations. Luckily,
> > history has shown that with time, hard work,
> > and lots of love, anyone can be a technocrat.
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bill Sommerfeld
> > > Sent: Friday, April 05, 2002 2:29 PM
> > > To: Jan Vilhuber
> > > Cc: Bill Sommerfeld; Paul Hoffman / VPNC; Tero Kivinen;
> > > ipsec@lists.tislabs.com
> > > Subject: Re: Do we actually need dynamic ports?
> > >
> > >
> > > > Well the draft that Pyda wrote changes the payload so
> that it's NOT
> > > > ambiguous (it tags each SA with a policy ID, so you always know
> > > > exactly which traffic-policy you're talking about (even if
> > > your SPI's
> > > > may change), and added an add/remove flag).
> > >
> > > I wasn't thinking of reordering within the KM protocol, but rather
> > > reordering between the KM protocol and AH/ESP traffic,
> especially in
> > > the case of selector deletion.
> > >
> > > If the SPI changes, we reduce selector-set changes to the same
> > > [un]solved problem as graceful rekeying ;-)
> > >
> > > 					- Bill
> > >
> >
>
>  --
> Jan Vilhuber
> vilhuber@cisco.com
> Cisco Systems, San Jose
> (408) 527-0847
>