[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP in IPSec
Loretta Zhou wrote:
>
> 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.
>
True! Excellent observation.
> > 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.
>
My point here was that you need to specify protocol=ICMP, AND ICMP
message type = (FragNeeded OR UndeliverableDueToTOS).
The explicit examination of particular ICMP message types/codes is the
requirement which exceedes the capabilities of IPSec Selectors.
> >
> > 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.
Perhaps an encryption expert could jump in at this point. My impression
is that you can infact decrypt partial packets if you don't sweat the
hash results (which would obviously be different). I don't know if it is
a good idea or not, but I did think it possible to decrypt partial
packets.
>
> 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.
Not impossible, just very unlikly. Different vendors IP stacks return
different amounts of the original IP datagram in an ICMP message. The
RFC only says that you must include at least the header and first 8
bytes. An ICMP message is perfectly capable of carrying more than header
+ 8 bytes of original packet, it just depends upon how that vendors
stack was implemented.
I have not done any 'survey of the market' to see what different
implementations do. If we want to make the assumption that we will ONLY
have header + 8 bytes to look at, thats ok with me, but it is an
assumption.
>
>
> >
> > 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.
I understand the temptation here but disagree. The particlular messages
we are talking about sending back in this circumstance are FragWasNeeded
or UndeliverableDueToTOS. If we send the TOS message to an incorrect
host, but that host does just happen to have a current flow which the
ICMP meesage might match as to its socket parameters, then we could
destroy TOS policy distinguising the real host the message needed to go
to and the actual host we 'accidently' sent the message to.
But on the other hand, perhaps your idea does make sence for the
NeededToFragment message. Perhaps some other voices could chime in here.
>
> 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".
>
We are undertaking the task of rethinking those sentences. As I said
above, I think your concept has merrit for PMTU applications, but is
dangerous to TOS policies.
> >
> > 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
I thank you very much for your input Loretta!!!
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
end Howdy;