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

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