next up previous
Next: Extensions to IKE Up: No Title Previous: Handling ICMP information messages

Handling ICMP error messages

ICMP error messages can be handled in two ways: one way is to handle them like the information messages -- establish selectors and SAs for them.

A second, more useful, way is to realize that every error message contains within it some portion of the IP packet which caused the error. It is therefore possible to examine this IP packet, compare it to existing selectors, and insert the ICMP message into an appropriate SA. When doing comparisons, the source and destination designations must be exchanged.

This method has the advantage that it inherently works well for per-host, per-port, and whatever future selectors may be created. This method assumes that SAs are created in equivalent pairs. This is the case for IKE negotiated unicast SAs, but would not be the case for multicast SAs, or manually keyed ones in general.

At first take it may seem that this technique does not require any negotiation, and can be implemented as a local policy. This is not the case. The receiving end of the SA will do tunnel exit checking, and unless it is also implementing this policy will reject the packet and flag a security violation.

It is therefore necessary for an IKE proposal to carry the "ICMP error" processing attribute as part of the proposal. This would require an extension to IKE, likely in the form of a variation of the identity payload, initially in the private payload ID space protected by a vendor ID payload. It would be easy to deploy as even after standarization, it would not require a new ISAKMP version -- vendors that didn't recognize the proposal would simply not select it.


next up previous
Next: Extensions to IKE Up: No Title Previous: Handling ICMP information messages
Michael C. Richardson
1999-10-04