RE: Do we actually need dynamic ports?

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 4 Apr 2002, Sankar Ramamoorthi wrote:

>
>
> > -----Original Message-----
> > From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> > Sent: Thursday, April 04, 2002 5:29 PM
> > To: Michael Choung Shieh
> > Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC
> > 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.
>
> proposed where? - I do not see it in the requirements document.
> Are u implying the draft from pyada and you?
>

Proposed by this thread.

jan


> The requirement for minimizing the latency seems a genuine one,
> particulary when using service based vpns - since the hit is now
> potentially on every new connection.
>
>
> >
> > 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
> >
> >
>

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