[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Neighbour Solicitation messages and IPsec
Stephen writes:
>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.
True.Though I'm worried that we don't specify anywhere how to bypass and what,
possibly leading to interoperability problems.
>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.
Yes, I agree. ICMP-specific controls aren't the only option, by the way.
We could also have IPsec implementations hard code the handling of
certain messages. I've got a feeling that this is what implementors are
doing. (True?)
Please note also that it seems like we need to do *something*, i.e. the
requested functionality isn't optional nice-to-have features. If we don't
either specify the rules regarding some of these ICMPs and we don't
give fine-grained control to the user, the chances are that implementation
A isn't going to work with implementation B. For instance, in view of the
the problems with Neighbour Advertisement messages, implementation
A bypasses these messages alltogether (or at least for dynamic policies).
Implementation B however chooses to bypass the messages when there
is no SA yet, and to require the use of the SA when one has been negotiated.
You can get A to talk to B, but if reachability detection kicks in (uses
the NA messages too), packets stop flowing!
>>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
Yeah. You're right.
Jari
----
http://www.arkko.com