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

RE: some issues about IPSec




> I don't think I agree with either of your assertions.
> 
> The remote client is going to suffer from bandwidth constraints because
> they can't push out many bytes (slow modems).  Those people using 
> slow modems will want to squeeze as much bandwidth out of their modems
> as possible.  Adding another header cuts the number of bytes they can pump.
> In this case, tunnel mode would be a detriment.   The transformation is 
> trivial, the extra bytes are not trivial for 28.8 modem users.
> 
> I'm not sure why you think 100% of dial in implementations will be bump 
> in the stack.  I assume you mean bump in the stack by BIST.   I don't 
> agree.   And even if that was a common implementation, I'm not sure how 
> a bump in the stack implementation would benefit greatly by only doing 
> tunnel... Can you explain this? 
> 

Please see reference the post by Bronislav Kavsan <bkavsan@ire-ma.com> ,
on this subject.  This succinctly states the issue.

BTW, sorry about the typos, I meant BITS...

Jeffrey Goodwin

**  Ashley Laurent,Inc. **  Software Development  **     Consulting          **
*                                   *                                         *
* 707 West Avenue, Suite 201        *     voice: 512-322-0676                 *
* Austin, Texas 78701               *     fax  : 512-322-0680                 *
*                      web: http://www.osgroup.com                            * 
* Microsoft Solution Provider       *  	  Complete Systems Design/Development *
* Novell Professional Developer     *	  Systems Software/Device Drivers     *

> 
> 
> -----Original Message-----
> From:	Engineering [SMTP:osgroup@laurent.osgroup.com]
> Sent:	Friday, January 23, 1998 6:09 PM
> To:	Stephen Kent; Xuechen Yang
> Cc:	ipsec@tis.com
> Subject:	Re: some issues about IPSec
> 
> 
> > Jeff,
> > 
> > Transport mode has less overhead than tunnel mode, because there is no need
> > for a second IP header, and that by itself makes it attractive in many
> > instances.
> > 
> 
> O.K., so performance is the primary criteria (benefit) ?  Tunnel mode is
> *only* peer to peer, correct ?  
> 
> So the primary issue would be gateway to gateway scenarious, in which
> all the ESP/AH formatting is done in the gateway only, and not be done
> by the clients whose clear text traffic is transformed by the
> gateway ?
> 
> But for remote access clients (isp dial-ups) I don't see performance as an
> issue, and don't see the benefit of transport mode outweighing the
> drawbacks, because.
> 
> 1)  If a remote access client is doing peer to peer, the performance
> bottleneck isn't in the extra ESP/AH formatting, it's in the internet
> cloud (the isp hardware and routing process).
> 
> 2)  Probably 100% or close to it (correct me if I'm wrong please) will be
> running BIST implementations, and for this performance will be *better*
> using tunnel mode.
> 
> Given 1 and 2, it seems to be to the detriment of remote access clients to
> require tunnel mode (again, please correct me if I'm wrong).
> 
> However, since the specification does not preclude implementations from
> exclusively utilizing a tunnel mode security policy, I suppose the market
> place will determine the best solutions by the type of security gateways
> they implemented for remote access solutions.  It just seems like a waste
> of resources to require the implementation given the analysis contained
> herein for remote access BIST implementations.
> 
> Sincerely,
> Jeffrey Goodwin
> 
> **  Ashley Laurent,Inc. **  Software Development  **     Consulting          **
> *                                   *                                         *
> * 707 West Avenue, Suite 201        *     voice: 512-322-0676                 *
> * Austin, Texas 78701               *     fax  : 512-322-0680                 *
> *                      web: http://www.osgroup.com                            * 
> * Microsoft Solution Provider       *  	  Complete Systems Design/Development *
> * Novell Professional Developer     *	  Systems Software/Device Drivers     *
> 



References: