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

RE: Do we actually need dynamic ports?



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

>
> Option (b) is to "negotiate a new (expanded) SA" and introduce extra
> lantency.

How does it add latency over option a, which is negotiate an update?
It will be 1 round-trip in either case. Option b adds a delete
notification, but traffic can start flowing before the delete
notification, so no latency (over option a) is added.

In any case, unless we reopen the discussion I eluded to, you HAVE to
negotiate with the other end to widen the selectors, so 1 round-trip
is the minimum you can do safely.

jan


>  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
>

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