Subject: IPv6 Neighbour Solicitation messages and IPsec

From: "Jari Arkko" <[email-masked]>
Date: Fri, 8 Dec 2000 13:43:30 +0200

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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Dec 2000 17:04:29 +0100

In your previous mail you wrote:

=> there was a nice presentation by Dan McDonald at a previous IETF about
this (Adelaide, 47th, "Link shared secrets for ND") but no draft...

   I've run in to an interesting chicken-and-egg problem in this area as I'm
   developing an IPv6 IPsec implementation.

=> yes, ND should bypass the IPsec policy in some cases, for instance
if the policy applies to any protocol, including ICMPv6.

   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.
   
=> there is a discussion about the PF_KEY API in order to solve this issue
(is this API good for SPD setup is another point).

=> open issue, near no work about it!

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Dec 2000 11:16:30 +0200

Stephen Kent wrote:

> >       * Path MTU discovery. Consider the following case:
> >
> >          (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2)
> >
> >         Assume N1 wants to send traffic to N2, part of the path
> >         goes through an insecure network part, secured using
> >         VPNGWs 1 and 2. And now Path MTU discovery is in
> >         progress between N1 and N2. Assume the smallest MTU
> >         is at R2. Then an ICMPv6 Packet Too Big message must be
> >         sent back towards the VPNGW2. Should that message
> >         go to the tunnel? I think it should.
> 
> There is nothing to prohibit transmission of this ICMP message via
> the security gateways, if appropriate SPD entries exist.

You are right, but the context of the discussion was that a proposal
was made that all ICMPv6 messages should bypass IPsec processing in
order to avoid chicken-and-egg problems with some ICMPv6 messages. I
was trying to make the point that _some_ ICMPv6 messages at least
in _some_ situations have to go through IPsec. Hence, the "ignore
ICMPv6 in IPsec" solution doesn't fly. It was also suggested that
perhaps the difference lies in tunnel mode vs transport mode. However,
that distinction doesn't solve the problems either... two nodes on
the same link could well have tunnel mode policies for all traffic,
which would then prevent e.g. duplicate address detection to work,
which in turn would prevent all communications. Also, as per RFC
2401 we do not in general have the possibility to specify policies
for individual ICMP message types. Finally, one might have expected
multicast / unicast addresses to have a significance such that
we could say only unicast traffic gets IPsec protection, but apparently
this isn't always the case. For instance, when the Neighbour
Advertisement message is used as a reply in an address resolution
situation, it is a unicast message.

Instead, I think we need something else. What was previously lower
layer thing such as ARP, is now a proper IP packet in v6. In addition,
there is completely new functionality. These must be considered
when thinking about which messages should get IPsec protection,
and how.

The ICMPv6 messages can be classified as follows:

 No RFC  Name                 End-to-End        Required Before UDP works
  1 2463 Dest unreach            Yes                      No
  2 2463 Packet too big          Yes                      No
  3 2463 Time exceeded           Yes                      No
  4 2463 Parameter problem       Yes                      No
128 2463 Echo request            Yes                      No
129 2463 Echo reply              Yes                      No
137 2461 Redirect                No                       Yes
133 2461 Router solicit          No                       Yes
134 2461 Router adv              No                       Yes
135 2461 NeighSol/Resol          No                       Yes
136 2461 NeighAdv/Resol          No                       Yes
135 2461 NeighSol/Unreach        No                       No
136 2461 NeighAdv/Unreach        No                       No
135 2462 NeighSol/Autoconf       No                       Yes
136 2462 NeighAdv/Autoconf       No                       Yes

Note that Neihbour Solicitation and Advertisement play multiple roles,
address resolution, unreachability detection, and autoconfiguration.
The crucial thing in the above table is to note which messages are
necessary before two IPv6 nodes can exchange packets. For IPsec, the
relevant issue is if SAs can be negotiated using IKE which runs on
top of UDP. If not, such messages simply can not be protected with
dynamic SAs; for instance we can't send UDP messages before address
autoconfiguration has determined the suitable addresses to be used
and ensured that no duplicate addresses exist on the link.

So, what I would propose is that the ICMPv6 messages Redirect,
Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement
(except for reachbility detection) are never given normal IPsec
treatment. I.e., if I define my policies as always requiring
IKE & IPsec for all traffic, then these exceptional messages still
go in the clear and without IKE.

Furthermore, I would suggest that if protection is needed for the
exceptional ICMPv6 message set, then manually configured IPsec SAs
be used, enabling also the protection of multicast traffic. However,
in order to do things like this, the SPD must have sufficient expressive
power to distinguish ICMP messages types and roles.

Finally, I would propose that everywhere in the ICMPv6 specifications
where it says "AH", tunnel mode ESP would suffice as well.

Jari

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 19 Dec 2000 12:54:36 -0600

> for individual ICMP message types.

This passed the IESG in RFC 2894 (so it must be true):

   Note that for the SPD to distinguish Router Renumbering from other
   ICMP packets requires the use of the ICMP Type field as a selector.
   This is consistent with, although not mentioned by, the Security
   Architecture specification [IPSEC].

It's no contradiction with what you said, though.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 19 Dec 2000 14:09:29 -0500

> It's no contradiction with what you said, though.

It should also be said that many ipsec implementors recognize the need
to have special support for icmp in ipsec policy; besides icmp type,
there's also the matter of protecting icmp errors using the "same"
policy as the traffic that generated them..

					- Bill

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Dec 2000 13:00:49 -0500

Jari,

>go in the clear and without IKE.

I'm not an IPv6 expert, but it seems that the issue here is who emits 
the message, not just what ICMP message is being emitted.

An IPsec implementation (gateway or host) has an ability to bypass 
control traffic that it emits, irrespective of SPD contents. So, I 
would expect that ICMP messages used for neighbor solicitation, 
advertisement, and autoconfig, etc. would fall into this category. 
But, such traffic emitted by a host behind a security gateway ought 
not be bypass in all cases, since doing so creates significant covert 
channel opportunities.

>power to distinguish ICMP messages types and roles.

Today we provide port-level controls, for UDP and TCP traffic, so 
adding ICMP-specific controls represents a significant change. We'll 
have to evaluate the requirement for this sort of change very 
carefully.

>where it says "AH", tunnel mode ESP would suffice as well.

This last suggestion is a topic for a different debate, and I would 
suggest not including it in this discussion.

Steve