[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ICMP errors to IPSECed data?






What we have done for manual IPSEC (as opposed to what we
might do with IKE, because we are not yet sure what to do),
is to generate a set of extra rules for ICMP.  In particular,
to deal with ICMP type 3 code * messages.

Consider the scenario:

HostA --- R1 --- SG1 --- R2 --- SG2 --- R3 --- HostB
                  |              |
                   ==============
                  SA between these

For traffic from HostA to HostB, any errors between HostA and
SG1 (tunnel start point) are handled normally.  Since the packet
is in the clear, we basically assume that the network is trusted.
ICMP errors from R2 are a problem, as discussed extensively in
this mailing list.  I would be very cautious about relaying
port unreachables from some random DOS box purporting to be from
router R2, the untrusted part of the network.  Furthermore, for
IPv4, the offending IP packet does not contain enough information
for SG1 to necessarily relay the error back to HostA.  ICMPs from
R3 can see the cleartext IP packet, so can be useful, if they can
get back to HostA securely.  So by adding a rule at SG2 that
says that ICMP type3 from anybody in the remote subnet going
back to HostA go through the tunnel, you can take care of some of
the ICMP error cases.

One problem would be to ensure that random hosts in the untrusted
network do not route bogus ICMPs to HostA through SG2.  We basically
color our interfaces red and green to differentiate the "trusted"
and "untrusted" interfaces, so a further screen on the ICMPs would
say that ICMP type 3 from anybody on the *green* side of SG2 to
HostA go through the same tunnel that carries HostB to HostA traffic.

Other opinions?  What do we do with nested SAs, e.g., if an SA also
exists between HostA and HostB?

Vach Kompella
IBM Corp.
Network Security Product Development
kompella@us.ibm.com
Ph.: (919) 254-7281
Fax: (919) 254-4239



Markku Savela <msa@anise.tte.vtt.fi> on 09/30/99 09:30:54 AM

Please respond to msa@hemuli.tte.vtt.fi (Markku Savela)

To:   ipsec@lists.tislabs.com
cc:
Subject:  ICMP errors to IPSECed data?




In my implementation I have done the receive IPSEC processing "in
place" (replacing crypted data with clear data) before passing it to
the upper layer (TCP/UDP). Now it just occurs to me, that this is a
potential security leak if the upper layer generates ICMP (such as
port unreachable) and copies the received packet to the ICMP
(especially in IPv6, where much more of the packet is copied).

It is possible to have a policy that requires protection for specific
UDP/port combo, and a different policy for ICMPs (like no encryption).

Just wandering how this is actually solved by others?

 - keep the original packet untouched (and have require upper layers
   to be aware of this and have them use the original packet in their
   ICMP replies) [Not very tempting, as I don't like duplicating the
   buffer space requirement just for possible error situation]

 - have some "marker" on the packet, which stops the copying for such
   ICMP messages,

 - require that the policy writer is aware of such potential "leak"
   and specifies proper IPSEC for ICMP too [but, you could have high
   security on UDP(port=x) and some lower security for UDP(port=y),
   which one you specify for a possible ICMP]

 - should ICMP error messages actually get the security from a policy
   that matches the returned packet they are trying to report?
   [e.g. instead of matching ICMP to the selectors, match the
   contained packet instead (feels a bit complex and kludgy)]

Has this issue been discussed?

--
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/