[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Neighbour Solicitation messages and IPsec
Stefan Schlott wrote:
> functions of it) for the IPv6 stack of Linux, I finally allowed all ICMP
> messages to pass unprocessed - securing ICMP broke too many things; this
> is certainly not an optimal solution, but it'll have to be sufficient for
> the moment. I don't think it will make much sense to process some kind
This is a good first approximation to get things going. But I think it would be
useful to try and understand the ICMP issue in a bit more detail. I'm
thinking of a document that specifies how each ICMPv6 message should be
treated in terms of IPsec. There are a bunch of interesting cases.
* Ping. This is very useful for testing IPsec connections as well,
having it not inside IPsec would lose that functionality.
Not to mention the fact that on my computer, ping6 seems to
be the *only* IPv6 application.
* Path MTU discovery. Consider the following case:
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.
* Multicast messages. Their own story.
Also, yesterday I was in the Zero Conf WG meeting and saw that
Steve Hanna and Aidan Williams were talking about the use of
IPsec in securing some of the early configuration messages
in a ZC network. Their problems are quite similar to what
we're experiencing in the v6/IPsec case, namely that it is
hard to use UDP in IKE, for instance, to build an SA
for messages that are going to select IP addresses. Their
solution seemed to be the use of manually configured IPsec,
which enables also the protection of multicast destined
traffic or packets with src address of zero (and avoids
IKE in a home appliance, which I think is a good thing).