Re: rfc4201bis issue #91: Handling ICMP error messages

[Joe Touch <touch@ISI.EDU>]

Theodore Ts'o wrote:

> (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".

"interface" should be sufficient; 'physical' is not a requirement 
anywhere else in either 2401 or 2401-bis.

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

How is an incoming ICMP different from any other sort of traffic 
destined to the router? It would be useful to limit the statement to 
those aspects only, rather than reiterating or creating
mechanims.

Joe

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