> > A slight correction. IPSec is also NATable if you are not using the
> > Authentication Header (AH). Use of AH or AH/ESP mode through NAT
> >breaks because NAT packet mangling makes HMAC checksums calculate
> >to an incorrect value. (See RFC 2709)
<Ben Nagy wrote>
> Um, and if your auth is not based on IP addresses, and if you're not doing
> PAT, and if the moon is in Jupiter, preferably waxing.
Ouch, he comes out with no gloves on. I will address this response in two
portions.
1) I am fairly certian that use of heavenly bodies as premises to arguments
is "off topic for this list."
2) Ben is right. The circumstances in which IPSec/NAT are implemented may
be dependant on several
variables and thus limit the circumstances it can/should be used. So I will
further qualify my previous statement a bit more as
I am still a bit sore from the slap in the face from Ben. IPSec/NAT is
supported. From a security perspective, implementation
of IPSec/NAT will not support AH for integrity/authenticity protection.
>From a reality standpoint, IPSec/NAT is around in
a large number of environments.
Best Regards,
Sam
> >If you are going to understand IPSec I suggest first finding documents
> >relating to the overall architecture. With reference to IPSec you should
> >understand ESP and AH and their uses in the architecture before you try
to
> >comprehend the specific algorithms used to implement IPSec. Search for
> >articles/RFCs written by Stephen Kent. This is a good source for
foundational
> >documents on IPSec.
http://www.networksorcery.com/enp/authors/KentStephen.htm
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
