[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with ICMPs
I am starting on a public domain implementation of the Ah and ESP Protocol
for Unix System V Systems (Solaris 2.X) . Because I can not change the IP layer,
I will position the security layer between the ip layer and the network
devices (dlpi).
This will force my implementation to act like a encrypting firewall
as described in ipsec-arch section 5.1 .
What should be done by a encrypting firewall when it receives an ICMP
datagram like "source quench" or "message to long" from a router in respones
to an encrypted datagram?
I am at the moment not concerned about security issues arrising from ICMPs
but on how to handle them transparent in a normal way.
All information that can be read from a ICMP datagram is the destination
address, the source address and the SAID of the IP packet that caused
the ICMP.
This does nor provide enough information for the firewall to generate a
normal ICMP datagram to pass it to the source of the offending datagram.
The only solution I see is that the encrypting firewall stores all datagrams
(at least the IP header and the first 64 bytes) it encrypts for a limited
time ( 2 * TTL ?) and tries to match incomming ICMPs with the stored datagrams.
If a match is found the ICMP datagram is modified and passed on.
Modification of the ICMP "message to long" should include adjusting the
"Next-Hop-MTU field" to allow "Path MTU Discovery" to work.
This solution would handle ICMP transparent to the existing IP definition.
But I think even considering some optimizations for protocols like TCP
it is to expensive.
It will also work for simple firewall configurations only.
I believe the same problem exists even when putting the security layer
between the protocols TCP,UDP and the IP layer.
Is there an easier solution to the problem?
Or even better - did I miss something and there is no problem ?
Stephan