[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: Friday, April 05, 2002 9:41 AM
> 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:
>
> >
> > 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,
I believe I was the initiator of the discussion that is being eluded to
- inband signaling seems to be considered taboo by many (personally I am
convinced that esp would have benefitted many ways with some provision
for control information, like a few flag bits. We never know what the
future requirements bring - I feel it would have been prudent to
have introduced atleast a few bits for flags and version#.
protocols such as IP, TCP have it. As for performance considerations,
many IP packets gets processed in the fast path as ESP).
My other proposals such as using a reserved spi to encapsulate the
original esp packet to indicate the presence of control information
was mainly a way to workaround the initial limitation of absence
of control bits in the esp header.
Having said that, I agree with you if we rule out inband signaling
as an option, a minimum of 1 roundtrip overhead is unavoidable
- atleast I cannot think of any.
The question I have is 200-500ms roundtrip delay (from Tero's
observation) acceptable latency for the expected spectrum of
dynamic protocols? I found that from talking to some of my team
members that for H.323 atleast since this delay will occur only
during call-setup time, it is acceptable.
Is it the same case for other so called dynamic protocol scenarios?
-- sankar --
>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
>
>