RE: Do we actually need dynamic ports?

[Michael Choung Shieh <mshieh@netscreen.com>]

Option (b) is to "negotiate a new (expanded) SA" and introduce extra
lantency.  You don't need to reopen any discussion.

However, I guess you recognize it adds more or less lantency to both
options.

Michael Shieh

-----Original Message-----
From: Jan Vilhuber
To: Michael Choung Shieh
Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC
Sent: 4/4/02 5:28 PM
Subject: RE: Do we actually need dynamic ports?

On Thu, 4 Apr 2002, Michael Choung Shieh wrote:

>
> Doing extra IKE to creat a new sa DURING application will introduce
extra
> latency and it may cause packet drop or retransmit.  It's probably not
> preferred if every FTP put/get will delay one or two seconds when
passing
> through IKE.
>

I don't think I'm going to reopen that discussion. We're talking about
the option of:

a) negotiate an 'update' to an SA
or
b) negotiate a new (expanded) SA and delete the old one

In both cases you need an active phase 1 IKE SA. If you still have one
around, no extra expense is incurred. If not, you'll need to add one.

Doing this without negotiatiing something wasn't one of the proposed
options.

jan


> --------------------------------------------
> Michael Shieh
> --------------------------------------------
>
> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Thursday, April 04, 2002 12:11 PM
> To: Tero Kivinen
> Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC
> Subject: Re: Do we actually need dynamic ports?
>
>
> I don't mind that. I just had to go re-read ikev2 and realized that
> you CAN in fact to multiple discontiguous ranges (or ports as well as
> IP addresses, by simply having multiple 'Traffic Selector
> Substructure' sections (7.13.1 Traffic Selector Substructure). Cool. I
> like it.
>
> The only minor difference (and I'm not saying it's important) is that
> you have to go through 'more' computation to delete and add a new SA,
> rather than adding to it, but that may be minor and not an issue at
> all. In particular: using up 'precious' entropy by having to come up
> with new key material, having to create a new SPI (and associated IKE
> delete payloads), and possibly having to rebuild some internal tree
> for the SA's (depends on implementation). Simply adding some selectors
> to an existing SA and keeping keys and SPI, *seems* easier, but may
> not actually make that much difference.
>
> Paul proposed using a semantic where using the same 'SPI' in the
> proposal means that you are adding to the existing SPI. That could
> bear a closer look as well, although I think there's room for error
> there..
>
> Negotiating a new SA, with new SPI, deleting the old one is certainly
> 'clean' even though it seems to involve a lot of steps. Are we going
> to try and fold some (not all) of the jenkins rekey-draft into IKEv2,
> so that rekey behaviour is spelled out precisely? That would certainly
> help.
>
> jan
>
>
>
> On Thu, 4 Apr 2002, Tero Kivinen wrote:
>
> > vilhuber@cisco.com (Jan Vilhuber) writes:
> > > This is no different than creating a second SA, I suppose. You
want
> > > traffic for the FTP data channel? Create a new SA for
> > > it. Alternatively, and this is what Pyda's and my draft does, pass
an
> > > indicator that identifies the previous SA, and ADD to it. Saves
> > > memory, at almost no additional cost.
> >
> > Why have a special case for ADD and DELETE, why not simply
renegotiate
> > new SA with new set of selectors (i.e add new selectors, remove the
> > ones you do not want), and when that new SA is ready, delete the old
> > SA. I.e simply make ADD and DELETE to be rekey of the existing SA.
> >
> > For IKEv1 you could not do that, as there was no way to express the
> > set of selectors, but with TS we can do that, so now that is an
> > option.
> > --
> > kivinen@ssh.fi
> > SSH Communications Security                  http://www.ssh.fi/
> > SSH IPSEC Toolkit
http://www.ssh.fi/ipsec/
> >
>
>  --
> Jan Vilhuber
vilhuber@cisco.com
> Cisco Systems, San Jose                                     (408)
527-0847
>

 --
Jan Vilhuber
vilhuber@cisco.com
Cisco Systems, San Jose                                     (408)
527-0847