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

RE: Do we actually need dynamic ports?





 > -----Original Message-----
 > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
 > Sent: Thursday, April 04, 2002 6:54 PM
 > To: ipsec@lists.tislabs.com
 > Subject: RE: Do we actually need dynamic ports?
 > 
 > 
 > At 6:44 PM -0800 4/4/02, 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?
 > 
 > No, in the (a) and (b) list that I proposed above. 

My mistake.

 > There has to be 
 > some negotiation: it isn't OK for the sender to say "I'm going to 
 > open up this port on your box because I want to and you can't do 
 > anything about it".

Was never in disagreement with this.

 > 
 > >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.
 > 
 > We are not talking about new connections here: we are talking about 
 > dynamically changing the policy in an existing SA to include more or 
 > fewer ports.

Are'nt they interrelated in the case of dynamic port scenario?
Any time a new connection is formed with a port that is allocated
dynamically, there is a requirement to change the policy in an
existing SA to include the new information - similiarly there is
a need to delete the port information when a connection using it
torn down.

One could minimize the overhead by varying the granularity, but
the basic problem of additional delay overhead remains.


 > 
 > --Paul Hoffman, Director
 > --VPN Consortium
 >