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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
