[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 Neighbour Solicitation messages and IPsec




I'm wondering if there are any documents that specify rules regarding the
use of IPsec in the context of IPv6 Neighbor Solicitations and possibly
other ICMPv6 messages.

As defined by http://www.ietf.org/rfc/rfc2461.txt, and http://www.ietf.org/rfc/rfc2462.txt
such IPv6 messages are needed to perform the address resolution, address
autoconfiguration, and duplicate address detection tasks. It seems that in some
cases these messages can be unicast messages between the two nodes.
(When the messages are multicast, IPsec doesn't apply.) It also seems that
regular packets can't flow until the ICMPv6 packets have been exchanged,
making sure the nodes know the link layer addresses and that no duplicate
addresses are in use.

I've run in to an interesting chicken-and-egg problem in this area as I'm
developing an IPv6 IPsec implementation. If I set my policies in a way that
all traffic in a LAN/WLAN should be protected with IPsec, then even some of these
ICMPv6 messages are trapped by IPsec. In order to establish a security association,
IKE needs to exchange a few UDP packets. However, if normal traffic can't
flow until the ICMPv6 messages are exchanged, how can the UDP packets
get through? In IPv4, this problem doesn't exist as either the corresponding
functionality does not exist (duplicate address detection) or runs at a lower
layer (ARP).

http://www.ietf.org/rfc/rfc2401.txt talks a lot of IPv6 and ICMP, but doesn't
seem to help in this matter. Also, the SPD requirements outlined in this
RFC do not seem to be general enough to distinguish e.g. Neighbour
Solicitations from Echo Requests, making it hard to define the policies
in a suitable way.

Can some folks who have done this before let me know how this should work,
point to some existing documentation, or perhaps correct my understanding
of the ICMPv6 operations.

Thanks,

Jari Arkko
Ericsson




Follow-Ups: