(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