IPSECAH(4P) Protocols IPSECAH(4P)
ipsecah, AH - IPsec Authentication Header
drv/ipsecah
The ipsecah module (AH) provides strong integrity, authentication,
and partial sequence integrity (replay protection) to IP datagrams.
AH protects the parts of the IP datagram that can be predicted by the
sender as it will be received by the receiver. For example, the IP
TTL field is not a predictable field, and is not protected by AH.
AH is inserted between the IP header and the transport header. The
transport header can be TCP, UDP, ICMP, or another IP header, if
tunnels are being used.
AH is implemented as a module that is auto-pushed on top of IP. The
entry /dev/ipsecah is used for tuning AH with ndd(8).
Current authentication algorithms supported include HMAC-MD5 and
HMAC-SHA-1. Each authentication algorithm has its own key size and
key format properties. You can obtain a list of authentication
algorithms and their properties by using the ipsecalgs(8) command.
You can also use the functions described in the
getipsecalgbyname(3NSL) man page to retrieve the properties of
algorithms.
Without replay protection enabled, AH is vulnerable to replay
attacks. AH does not protect against eavesdropping. Data protected
with AH can still be seen by an adversary.
See attributes(7) for descriptions of the following attributes:
+--------------------+-----------------+
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|Interface Stability | Committed |
+--------------------+-----------------+
getipsecalgbyname(3NSL), ip(4P), ipsec(4P), ipsecesp(4P),
attributes(7), ipsecalgs(8), ipsecconf(8), ndd(8)
Kent, S. and Atkinson, R. RFC 2402, IP Authentication Header, The
Internet Society, 1998.
September 25, 2009 IPSECAH(4P)
NAME
ipsecah, AH - IPsec Authentication Header
SYNOPSIS
drv/ipsecah
DESCRIPTION
The ipsecah module (AH) provides strong integrity, authentication,
and partial sequence integrity (replay protection) to IP datagrams.
AH protects the parts of the IP datagram that can be predicted by the
sender as it will be received by the receiver. For example, the IP
TTL field is not a predictable field, and is not protected by AH.
AH is inserted between the IP header and the transport header. The
transport header can be TCP, UDP, ICMP, or another IP header, if
tunnels are being used.
AH Device
AH is implemented as a module that is auto-pushed on top of IP. The
entry /dev/ipsecah is used for tuning AH with ndd(8).
Authentication Algorithms
Current authentication algorithms supported include HMAC-MD5 and
HMAC-SHA-1. Each authentication algorithm has its own key size and
key format properties. You can obtain a list of authentication
algorithms and their properties by using the ipsecalgs(8) command.
You can also use the functions described in the
getipsecalgbyname(3NSL) man page to retrieve the properties of
algorithms.
Security Considerations
Without replay protection enabled, AH is vulnerable to replay
attacks. AH does not protect against eavesdropping. Data protected
with AH can still be seen by an adversary.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
+--------------------+-----------------+
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|Interface Stability | Committed |
+--------------------+-----------------+
SEE ALSO
getipsecalgbyname(3NSL), ip(4P), ipsec(4P), ipsecesp(4P),
attributes(7), ipsecalgs(8), ipsecconf(8), ndd(8)
Kent, S. and Atkinson, R. RFC 2402, IP Authentication Header, The
Internet Society, 1998.
September 25, 2009 IPSECAH(4P)