Re: handling of ICMP error codes in 2401bis

[Markku Savela <msa@burp.tkv.asdf.org>]

Few, somewhat delayed comments...

First, my view is

 When an ICMP error message is generated from ESP protected incoming
 packet, then the *ONLY* valid handling alternatives are

  1) do not send the ICMP error

  2) apply protection based on the selectors of the received packet
     (as proposed by Michael Richardson)

Doing anything else, may break the security.

   Just having some policy and IPSEC protection for ICMP errors could
   be sufficient, if it is the strongest protection in the policy
   (otherwise, errors occurring in strongly secured flows mignt cause
   a leak of information). But, I think this will create security
   pitfalls for unwary administators.

However, in the proposal...

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

Taking into account the choices (1) and (2), I don't think negotiation
is necessary. Either you do the policy check based on the error packet
or you drop the ICMP.

---

Implementing this logic for IPv4 is fairly simple and easy (I've done
it). However, IPv6 and extension headers will cause some
implementation difficulties, consider

  IP ESP DOP EXT TCP ...

(e.g. DOP=Destination Option, EXT some other extension header). If
ICMP is generated in DOP (unknown options or something), there is a
problem with IPSEC finding out the proper selectors from TCP headers,
unless it also knows the format of EXT header (otherwise it will just
assume EXT as upper layer).

Not really unsolvable, just adding some complexity. Adding a new
extension header implementation needs to provide a way for IPSEC to
skip over it...