Subject: Re: IPv6 Neighbour Solicitation messages and IPsec

From: "Jari Arkko" <[email-masked]>
Date: Mon, 8 Jan 2001 00:18:43 +0200

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

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