rfc4201bis issue #91: Handling ICMP error messages

["Theodore Ts'o" <tytso@mit.edu>]

(Resending this message with the correct subject line)

Looking at the issues left according to roundup that are still pending,
most of them are related to the new processing model, for which we are
awaiting new text from Steve Kent and Karen Seo.  One of the other
issues is issue 91, which has not recenved much discussion to date.
This note is intended to hopefully spur that discussion.

I will note that the proposed text contains two distinct sections.  The
first part is much more formal, and the second is much more informal and
uses a particular topology as an example (with plenty of references to
"red" and "black" sides).

In the first section the follow formal requirements are stated:

	To accommodate both ends of this spectrum, a compliant IPsec
	implementation MUST permit a local administrator to configure an
	IPsec implementation to accept or reject unauthenticated ICMP
	traffic.  This control MUST be at the granularity of ICMP type
	and MAY be at the granularity of ICMP type and code.
	Additionally, an implementation SHOULD incorporate mechanisms
	and parameters for dealing with such traffic. For example, there
	could be the ability to establish a minimum PMTU for traffic
	(perhaps on a per destination basis), to prevent receipt of an
	unauthenticated ICMP from setting the PMTU to a trivial size."
	[See issue 78 for PMTU minimum size recommendations]

This paragraph specifies that the acceptance/rejectance criteria for
unauthenticated ICMP traffic is at the granularity of the ICMP type.
However, notably missing from this requirement is any mention that the
granulairty should perhaps include which physial interface a packet was
received, since some interfaces are considered as being connected to a
"trusted" network, while others are considereed "untrusted".


In the second section, which begins "Consider a topology along the lines
of...", the text becomes much more informal, with many ASCII art
diagrams, and which actually uses the terms "trusted source" and
"untrusted source".  In addition, the ASCII art at least presumes the
use of tunnel mode, and the discussion is very verbose.  It is not clear
what an implementation is supposed to do given a different topology than
the example given at the beginning of this section.

It seems to me that most of the rather long verbiage can be boiled down
to a statement that the ICMP packet should be sanity checked based the
information found in the SPD, and that the administrator must be able to
determine whether or not unauthenticated ICMP messages from a particular
network are to be accepted as true without other forms of verification

Is there a way, perhaps, that the proposed text given in issue 91 on the
roundup tracker might be simplified?

						- Ted