[nsp] OSPF & Encryption
dsinn at dsinn.com
Tue Nov 18 15:25:21 EST 2003
One problem with using a IP MTU of 1500 on the tunnel interfaces is that the
receiving end will process switch any packets that need to be reassembled.
This can seriously impact your performance, so take care in doing this.
It does fix the broken PMTU problems that can result when you have to be on
links smaller then 1500, so some times it is the only option.
On 11/18/03 9:16 AM, "atticus at satanic.org" <atticus at satanic.org> wrote:
>> We also want to run OSPF.
> As you mentioned, tunnels are really the only way to make this work. The
> one upside is the usual caveat is dealing with reduced MTU (..and I've
> found that not dealing with the fragmentation appropriately can introduce
> as much overhead as the crypto), but since you'll own both end of the
> serial interfaces, you can bump this up so that you can effectively
> maintain an end-to-end 1500 mtu..
>> I was going to encrypt the links using IPSec but this breaks OSPF. Cisco's
>> solution seems to be to use GRE tunnels - something I don't have experience
>> with. Is there a simpler way?
>> Are there alternatives to IPSec for encrypting point-to-point links?
> Staying within the Cisco realm, I believe your only option (and its not
> really an option) is doing MPPC within PPP. I've only ever done this for
> the case of PPTP, but it _should_ work.
>> We have customers (we're in the financial industry) that insist that we
>> encrypt our private T1s.
> Though you might not like the answers, they're obviously already doing it
> in some/many places, just ask them for a tech contact. Most financials
> that I've done business with have a team of fulltime security people
> examining your orafices that enjoy talking about this stuff.
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp