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

RE: Simplifying IKE


RFC 2207 allows you to select RSVP flows based on the SPI.

	 Mike

Chris Trobridge writes:
 > There is always TOS.  Packet length, even?
 > 
 > How can you use the SPI to sort traffic?  This assumes the access router
 > knows which SPI corresponds to which traffic.
 > 
 > Actually classifying traffic after applying ESP is a major hasssle for ISPs.
 > OTOH, they don't often understand the security consequences of leaking the
 > sort of info classification uses - which is often into the application
 > layer!
 > 
 > Chris
 > 
 > > > I'd also like to see all IPSEC traffic between two hosts 
 > > carried by just one
 > > > SA.  I can't see any value in using multiple SAs between to 
 > > hosts.  IPSEC
 > > 
 > > there is. and it's not related to security at all.
 > > 
 > > suppose you have slow internet connection that is used only for VPN
 > > traffic. your access router has no way to distinguish between 
 > > different
 > > sessions inside your VPN so it will put all the packets into 
 > > same queue.
 > > if somebody is moving large file using ftp your telnet 
 > > connection will be
 > > very very slow.
 > > 
 > > without encryption the routers will put packets from separate sessions
 > > (defined by src&dst IP, protocol and ports) into seprate queues (cisco
 > > calls them classes IIRC) and even if you are downloading some 
 > > huge file
 > > your telnet session is still usable.
 > > 
 > > with encryption the SPI is the only parameter that can be 
 > > used to classify
 > > the packets. if you are using a single SA between two hosts it's
 > > impossible for routers to distinguish between packets from different
 > > sessions and the interactive applications suffer really bad.
 > > 
 > > arne
 > 
 > 
 > -----------------------------------------------------------------------------------------------------------------
 > The information contained in this message is confidential and is intended 
 > for the addressee(s) only.  If you have received this message in error or 
 > there are any problems please notify the originator immediately.  The 
 > unauthorized use, disclosure, copying or alteration of this message is 
 > strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
 > special, indirect or consequential damages arising from alteration of the 
 > contents of this message by a third party or as a result of any virus being 
 > passed on.
 > 
 > In addition, certain Marketing collateral may be added from time to time to 
 > promote Baltimore Technologies products, services, Global e-Security or 
 > appearance at trade shows and conferences.
 >  
 > This footnote confirms that this email message has been swept by 
 > Baltimore MIMEsweeper for Content Security threats, including
 > computer viruses.
 >
References: