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

Re: IPv6 Neighbour Solicitation messages and IPsec


<excerpt>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

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

  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

(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.


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 <underline>it</underline> 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.


<excerpt>Furthermore, I would suggest that if protection is needed for

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

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


Finally, I would propose that everywhere in the ICMPv6 specifications

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.