[c-nsp] IPSEC Transport mode

Jeremy Stretch stretch at packetlife.net
Wed Jun 18 10:06:00 EDT 2008


Some good info on the operation of accelerators often found attached to 
satellite links:

http://www.scps.org/scps/html/tcp_peps.html

To summarize, TCP ACKs are generated/dropped locally at either end 
rather than being forwarded across the satellite link. Of course, this 
doesn't work on encrypted data. The accelerators have to be placed 
somewhere between the end clients and the device performing encryption.

[client] -- [accel] -- [crypto] -- [sat] -- [crypto] -- [accel] -- [client]

stretch
http://packetlife.net

Fred Reimer wrote:
> That doesn't make sense.  Encrypt the traffic "before" acceleration from
> what perspective?  From looking at it from the WAN in between the two
> sites?  That I can see, but that's not usually how VPN's and encryption
> are described, and can confuse a lot of people.  If described in the
> normal way, from the perspective of the main or local site and not
> within the WAN, then I fail to see how an acceleration device would be
> able to "accelerate" encrypted traffic.  I can see how an acceleration
> device may be able to accelerate traffic before it is encrypted and sent
> over the WAN.  That would describe a normal VPN connection, and you
> would theoretically be able to put your WAN acceleration device in-line
> between your remote site and the WAN router/ASA.
>
> If the acceleration device "ignores" ESP and says they can accelerate a
> non-ESP connection, then that means to be they require AH, which isn't
> encryption at all and just authentication (that the data didn't change,
> and hence would fail anyway if the acceleration device modified the data
> which it presumably has to do to reduce the number of bits sent).
>
> I think there is a large misunderstanding, possibly on my part, as to
> what the design requirements are.
>
>
> Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
> Senior Network Engineer
> Coleman Technologies, Inc.
> 954-298-1697
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ziv Leyes
> Sent: Wednesday, June 18, 2008 10:12 AM
> To: Jeremy Stretch; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] IPSEC Transport mode
>
> We need to find a way to encrypt the data BEFORE the acceleration and
> from what I've read, is not possible to accelerate TCP when the data is
> inside an encrypted tunnel, so the possible way to be able to spoof the
> TCP is in transport mode instead of tunnel mode of the IPSec.
> But that's only based on what I've read on the web, perhaps I'm missing
> something.
> If the only way to do it is using only two routers, is somebody willing
> to share a sample config of a GRE/IPIP tunnel with transport encryption
> within?
> Thanks,
> Ziv
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeremy Stretch
> Sent: Wednesday, June 18, 2008 12:32 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] IPSEC Transport mode
>
> Ziv,
>
> I have a setup very similar to what you describe, a transport mode
> tunnel between two 3725s connected via satellite. We have accelerators
> in place but I'm not familiar with them. It's a fairly standard setup;
> what do you need to know?
>
> stretch
> http://packetlife.net
>
> Ziv Leyes wrote:
>   
>> Hi,
>> I'm making a VPN Site to Site tunnel in a lab test between a Cisco
>>     
> 1840 router and ASA5510, each one connected behind a satellite link,
> because of the high latency in such setup (1300ms RTT) we're trying to
> implement acceleration and the appliance we're trying to implement needs
> the VPN to encrypt in transport mode in order to be able to accelerate
> the traffic, the appliance knows to "ignore" the ESP protocol and
> accelerate/compress the data, it can't do nothing on an IPSec in tunnel
> mode.
>   
>> I searched the web and the only thing I've found was a proposed setup
>>     
> with GRE or L2TP tunnel and then encrypting the data that goes through
> the tunnel.
>   
>> Does somebody know what I'm talking about? I'll appreciate some ideas.
>> Thanks,
>>
>> Ziv
>>
>>
>>
>>
>>
>>
>>
>>
>>     
> ************************************************************************
> ************
>   
>> This footnote confirms that this email message has been scanned by
>> PineApp Mail-SeCure for the presence of malicious code, vandals &
>>     
> computer viruses.
>   
> ************************************************************************
> ************
>   
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>     
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
>
> ************************************************************************
> ************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> ************************************************************************
> ************
>
>
>
>
>
>
>  
>  
> ************************************************************************
> ************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> ************************************************************************
> ************
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>   



More information about the cisco-nsp mailing list