[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP in IPSec
Ricky Charlet wrote:
>
> So Sgw1 has four questions to answer about ICMP messages
> received from R1 intended for return to E1'.
> 1. Is this message intended for me directly or for some endpoint I
> protect?
> 2. Is this an interesting message?
> 3. Do I trust the message?
> 4. Is there enough information in the message to be useful to E1'?
>
> To answer question number 1 above use the following logic: If
> message is an ICMP query, then it is not for E1'... respond to ICMP
> queries to this interface as per local interface policy. If message is
> an ICMP error, then examine the original offending packet data IPSec
> Header field for a valid SPI number. Presence of an SPI implies that
> this message is intended for some endpoint and not for the Sgw itself.
> If the message is in fact intended for this Sgw, then local policy
> should specify whether to handle/respond or ignore the message.
>
I think another way of identifying whether the message is intended
for sgw or endpoint is to check the protocol field of the IP header
attached to the ICMP message. If the protocol is AH or ESP, it indicates
that the original offending packet was a tunneled packet and the message
is intended for some endpoint protected by Sgw1. If the protocol field
returns a value other than AH/ESP, it indicates that the ICMP message is
for the security gateway.
In my opinion, this approach is easier than looking for a valid SPI
number.
> If message is intended for some endpoint behind this gateway,
> and local policy allowed ICMP processing on this interface, then proceed
> to question 2 from above.
>
> To answer question number 3 above, the only secure course is
> to not trust messages appearing at Sgw1 which did not arrive in an SA.
> But an Operations and Maintenance group might evaluate the security risk
> (DOS attack) of accepting these limited IMCP error messages as worth the
> value of knowing about PMTU, and/or TOS reachability. So they will need
> a configurable option to allow each of these messages. The IMCP
> configuration MUST allow for explicit pass/block filtering on
> Fragmentation Needed messages, and on TOS messages. These filter rules
> are over and above what is achievable with IPSec selectors.
>
Is it really necessary to have an explicit filter sitting above the
IPSec selectors in SPD? If an administrator wants to let all or certain
ICMP traffic to bypass IPSec, he can always add an entry to the top of
the
SPD table stating that for traffic with "protocol=ICMP, srcAddr=* or
some
subnet address, dstAddr=* or some subnet address", apply bypass action.
I noticed that sometimes you suggest handling ICMP error messages using
these special configurable filters, and some time you mention that the
ICMP error message needs to be checked against local policy (the SPD).
It seemed to be a little confusing to me when to check against what.
>
> Recovering the inner IP header in the case of an AH tunneled
> packet requires that we be able to see the entire outer IP header (20
> bytes +options) the entire AH header (32 or more bytes), 20 or more
> bytes of the inner IP header (full header sans options) and 8 bytes of
> inner IP payload. If there is enough data present, then the inner IP
> packet header may be read. But it is extremely unlikely that the entire
> original IP packet was returned so that the data will not be able to be
> authenticated (but understand that if we have gotten this far, it means
> that an administrator has already made the choice to trust this
> information in spite of its inability to be authenticated).
>
> Recovering the inner IP header in the case of an ESP tunneled
> packet requires that we be ale to see the entire outer IP header (20
> bytes +options) and enough of the ESP packet so that we may reference
> the SPI and then decrypt enough of the payload data to reveal the inner
> IP header, optinos and first 8 bytes of data. Again, it is very unlikely
> that we will have the entire original IP packet and will not be able to
> authenticate, but a trust decisions has already been made in spite of
> this limitation.
>
Even though we are only intereseted in the inner IP header and the first
8 bytes after the header, we still need to have the entire encrypted
packet in order to get the right decryption. Having partial encrypted
packet will not result in the right decryption.
In fact, it's impossible to get the inner IP header at all if the
original offending packet is a tunneled packet. Keep in mind that
ICMP can only carry an IP header and 8 bytes of the datagram beyond
the header in its message body. When a packet is tunneled, the IP
header is the outer header and the 8 bytes datagram is the first 8
bytes of the AH/ESP header(the SPI will be included). The original
IP header will never be included in the ICMP message body and can
never be recovered from the ICMP message.
>
> If the original inner IP packet header cannot be recovered,
> cease all further processing related to handling this error and drop the
> ICMP packet. An implementation MAY wish to make this an auditable event.
> If the original inner IP packet header and the first 8 bytes of original
> IP packet data can be recovered, then the security gateway MUST
> construct a new IMCP error message. It MUST be addressed to the source
> address named in the original inner IP header. It's ICMP type, ICMP
> code, IP TOS, and IP precedence MUST match the old ICMP packet (now
> being discarded). And the data it contains MUST be the original inner IP
> packet header plus 8 bytes of the original inner IP packet data.
>
As mentioned above, I believe the inner IP header will never be recoverd
from the ICMP message for tunneled packet. Instead of dropping all the
packets, I suggest we store the packet with its SA (the SPI is included
in the ICMP message body so we can find the SA), and wait until the next
packet arrive from an originating host for the same SA. We will then
assume
the previous packet is also from the same originating host and we can
then
send the ICMP message (or a re-construct of the ICMP message) to that
host.
My idea of the above suggestion came from RFC 2401(security architecture
for IP) and RFC 2003(IP Encapsulation within IP). In section 6.1.2.1 of
RFC 2401, it indicates that a security gateway MUST support what I just
suggested in the above paragraph for propagation of Path MTU. In section
5 of RFC 2003, it also explictly stats that when an inner IP header
cannot
be determined due to encapsulation, the encapsulator should maintain
some
"soft state" about the tunnel and the encapsulator can return accurate
ICMP
messages to the original sender based on those "soft state".
>
> When Sgw2 decides to return an ICMP error to E1', similar
> processing occurs. Sgw2 creates the IMCP error message and MUST attach
> the entire offending IP packet and must ensure that the DF bit is
> cleared. Note, that at this point, the offending IP packet is in an
> un-encapsulated state. The ICMP packet which bundles the original
> offending IP packet is sent to E1' via Sgw1 through the complement SA of
> the SA it arrived on. Sgw1 recognizes that an ICMP packet to E1'
> arriving on an SA from the ISAKMP peer far end of the SA is allowable
> and forwards the packet.
>
Does Sgw1 make decision (allow the ICMP packet to pass to E1) based on
SPD or those special filters?
Regards,
Loretta Zhou
References: