On Tue, 20 Sep 2016, Bryan Harris wrote:

I'm just learning about ipsec and have been able to setup a host to host tunnel 
using x509 certificates signed by a dummy CA.

In some of the documentation I've read I can see an iptables rule to allow AH 
protocol packets, and after some testing I've become a little confused about AH 
packets.

For example, when I allow these in iptables and search for them via simple tcpdump 
command "tcpdump -n -i eth1 ah", I never seem to see them.  Am I missing any 
option in the command?  I
can see lots of esp packets, but ne'er any a drop of ah.

Another example, if I do not allow ah packets in my iptables, the tunnel still 
seems to work fine.  Of course, the iptables allows udp 500, 4500 and protocol 
esp.  I put the iptables -L
output at the bottom of this email.

Is ah really required in all scenarios or are there specific circumstances that 
ah packets  really get used by ipsec?  I noticed in the RHEL 6 Security Guide 
they say the AH requirement
is uncommon, so I wonder if I don't need that rule.

AH is protocol 51. ESP is protocol 50. So the arguments to tcpdump
are different (-p esp versus -p ah). In libreswan you configure
this with type=esp or type=ah

ESP is what you think of traditionally as IPsec - packet encryption.
AH is not doing encryption, but only doing integrity checks ("has the
packet been modified in transit?") AH is similar to ESP-NULL (null
encryption) There is NAT-Traversal support for ESP, but not for AH.

From the ipsec.conf man page:

phase2
        Sets the type of SA that will be produced. Valid options are:
        esp for encryption (the default), ah for authentication only.

        The very first IPsec designs called for use of AH plus ESP to
        offer authentication, integrity and confidentiality. That dual
        protocol use was a significant burden, so ESP was extended to
        offer all three services, and AH remained as an auth/integ. Only
        broken configurations (often used with racoon) require the strange
        double authentication using ah+esp. Additionally, AH does not play
        well with NATs, so it is strongly recommended to use ESP with the
        null cipher if you require unencrypted authenticated transport.


Almost no one uses AH, yet the IETF is unable to kill it off. There is
always someone who wants to keep it in favour of ESP-NULL.

Paul
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to