[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Do we actually need dynamic ports?
> -----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?
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
>
>