[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reg. ICMP handling in IPsec
Hi Ricky,
I find your description very useful as it complimnets the section 6 of RFC
2401.
It seems that ICMP handling in IPsec is going to more prorietary way. But,
how does the products will support the SPD entries with requiremnet that
there should be a SA for Ping packets but separate action for ICMP errors ?
I have few questions regarding handling of ICMP messages from R1 to SGw1.
Based on the presence of SPI, you have marked that the message is meant for
E1'. So, did you assume that SGw1 is acting as purely router and it does not
support any of the managemnet applications like telnet/snmp which may use
transport mode SAs. If SGw1 is supporting the both kinds of SAs, then how it
will determine that the message is intended for me or the n/w supported
behind me , i.e. E1' .
regards
To: ipsec <ipsec@lists.tislabs.com>
Subject: ICMP in IPSec
From: Ricky Charlet <rcharlet@redcreek.com>
Date: Fri, 14 May 1999 21:04:45 +0000
Organization: RedCreek Communications Inc.
Sender: owner-ipsec@lists.tislabs.com
--------------------------------------------------------------------------------
Howdy ()
There exists a draft named draft-ietf-icmp-handle-44-00.txt
which is a template nameing each ICMP message and provides a space
describing how to handle that ICMP message. The draft is a
template because none of the descriptions are filled in. Back at the
44th (Minneapolis) I believe I recall the working group deciding that
ICMP handling needed to get more specific befor closing the group. There
was a call for volunteers to put in effort. I volunteered and here is a
bit of effort.
I have not followed Michael Richardson's draft (icmp-handle) in
my 'initial thoughts' post. I find it more clear to ponder these out in
terms of 'situational examples'. I hope (naively??) that my list of
situations is complete. The goal would be to move from my situational
format to filling in Michael's draft with the details per message rather
than per situation.
These are my initial thoughts. I am looking for feed back.
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
=====================
|| ||
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | |
| E1 |---|Sgw1 |---| R1 |---|Sgw2 |---| R2 |----| E2 |
| | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
E1' E2'
Terminology:
o E1 and E2 are IPSec endpoints. These endpoints are defined in Sgw1
and Sgw2 by IPSec selectors.
o Sgw1 and Sgw2 are IPsec Security Gateways.
o R1 and R2 are non-IPSec routers.
o E1' and E2' are derived from the deffinitions of E1 and E2. These
'prime' endpoints are defined only by IP address or IP Address
range. Whereas E1 and E2 may have been defined by IP address(range)
and ports and protocols, and/or fqdn, and/or user@fqdn etc...
ICMP traffic from Sgw1 to E1.
Sgw1 needs to ask itself if it trusts that the traffic causing
the ICMP event is really from E1, a trusted endpoint. Sgw1 may choose
to always trust that any traffic received from this interface is
authentic, may decide never to trust any traffic received on this
interface, or may decide that traffic received on this interface is
authentic only if its source address matches E1'. This matching, only
results in weak authentication which could easily be spoofed. The choice
of never trust, always trust, or match src address against E1' to
determine trust, when considering whether to respond to ICMP MUST be an
administratively configurable behavior per interface with the default
action being never to trust.
ICMP traffic from R1 to E1.
This is unexpected. R1 should never have any knowledge of E1's
IP address and therfore should not be able to direct ICMP messages at
E1'. All such ICMP traffic MUST be silently discarded by Sgw1 unless an
operator has configured an applicible bypass IPSec selector (this is NOT
recomended).
ICMP traffic from R1 to Sgw1.
Traffic from R1 does not arrive in an SA and is therefore of
highly suspect integrity. If R1 is sending an IMCP error message, then
the original offending IP packet returned with the ICMP error message is
almost certianly trunkated, possilby making it impossible to deterime
the original sender's IP address. Also, there are extremely few ICMP
messages which R1 might return that E1' could possibly be interested in.
These are "fragmentation needed", "unreachable due to TOS (net and
host)", and to a lessor degree "source quench" and/or ECN notifications.
The Fragmentation and TOS messages are of possible interest to E1'
because the associated bits from E1's IP header were copied to the
tunnel mode outer IP header and therefore exposed to the Internet which
might rerun valid errors related to these fields. Since the outer IP
header hides all other information about the inner IP header, no ICMP
reachable errors, or redirect errors, or TTL errors, or parameter
problem errors relate to the IP header which E1' sent. The only other
valid information that R1 may have for E1' would relate to flow control.
A source quench message inticates that E1' should take some flow
control action, but the soruce quench mechanism is depricated and
current router implementations are advised not to originate ICMP soruce
quench messages so these are safly ignorable. There is a new
experimental protocol called "Explicite Congestion Notification". If it
is ever embraced by the IPSec comunity, some people may wish to examine
how to make it work in this scenario. But as for now, ECN will not be
considered.
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.
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 2above, only the IMCP error messages:
o fragmentation needed but DF set
o network unreachable for TOS
o host unreachable for TOS
MAY be forwarded onward to E1'. All other ICMP messages intended for E1'
MUST be dropped. Now you may ask yourself, "What about all those
unreachable messages?" Receipt of an 'unreachable' IMCP error message on
Sgw1 while it was trying to send to Sgw2 is not a problem that E1 need
be informed of directly. It is an implementation concern with what to do
when tunneled traffic is attempting to reach an unreachable peer
gateway.
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.
To answer question 4 above, first understand the problem. It may
be that the IMCP error message did not bundle the entire original
offending IP packet. We know the original offending IP packet was a
tunneled packet with an outer IP header, and an IPSec header, and an
inner IP header and data and trailers. In order to be useful to E1', we
need to recover the original inner IP header and first 8 bytes of IP
data. This is because E1' will need to deliver this IMCP message to a
transport protocol, therefore E1' will need to identify the exact socket
this packet was sent from. Attempting to guess E1's identity from the
SPI# in the SA header (almost always present in the returned original
offending packet) will be insufficient to identify the exact socket on
E1' and is therefore a fruitless endeavor. But recovering the inner IP
header from the original offending packet may not always be possible.
And even if it is possible, it will most likely be a difficult endeavor.
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.
In cases of SA bundles where there are multiple transforms
applied, the SPI will indicate to us which transforms we need to undo
and how much of the original IP packet we need to recover.
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.
ICMP traffic from Sgw2 to Sgw1:
This situation occurs when Sgw2 receives an IP packet from Sgw1
which is addressed to Sgw2. This occurs frequently since Sgw2 is the
endpoint of a tunnel. This discussion should not be confused with Sgw2
deciding to send an ICMP error to E1', which might occur after tunnel
decapsulation. That situation is discussed in the next section.
Sgw2 may respond to an IMCP query from Sgw1, or may generate an
ICMP error to return to Sgw1. Sgw2 may respond to a query in the clear
if an IPSec selector matching protocol=IMCP and src address=Sgw1 allowed
the bypass action (Sgw2 might have query responded to anything in the
Internet if the bypass selector for protocol=ICMP had allowed). Sgw2 may
respond to an IMCP query from Sgw1 in an SA if the IPSec selector
specified a Secure action. (This SA might need to be negotiated, the
IMCP query response SHOULD be held until the SA is up).
Sgw2 MUST NOT ever decide to generate an ICMP error message to
Sgw1 at this point. Realize that this is before any SPI matching and
IPSec untransforming has cured. After IPSec untransforming has occurred,
Sgw2 may decide to send errors back to E1', that is covered in the next
section. At this point, there is no error message that Sgw2 could send
to Sgw1 which Sgw1 may find to be actionable. The IP packet was
obviously deliverable. It is not yet known if it is administratively
prohibited or TOS prohibited. It is not realistic to tell an ISAKMP peer
to redirect. Even if the packet times out during re-assemble on Sgw2,
this is not information that Sgw1 cares about (in a tunnel mode SA).
ICMP traffic from Sgw2 to E1':
After Sgw2 has SPI matched the tunneled packet and untransformed
the packet, it has the IP header and payload from E1' in hand.
Sgw2 may either realize that E1' has sent it an ICMP query or
that traffic sent by E1' destined for other locations, is offending and
it should send back an IMCP error to E1'. Because the traffic arrived
through an SA, Sgw2 MUST consider the traffic authentic. ICMP queries
should be handled as per relevant RFC and returned to E1' being sent
trough the complementary SA back to Sgw1. Sgw1 must be able to recognize
that ICMP traffic arriving in an SA, destined to E1' and sourced from
that SA's ISAKMP peer is allowable and forward the ICMP packet. Sgw1
MUST do this even if the SA selectors did not natrually allow ICMP
traffic.
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.
ICMP traffic from R2 to E1'
MUST be dropped by Sgw2 due to no match with selectors. But,
note a workaround here. If an operations and maintenance group wishes
to trust and allow these ICMP messages (from R2 to E1'), then they may
configure on Sgw1 and Sgw2, new selectors which match R1's IP addresses,
to E1's IP address(es) and protocol = ICMP. In this case, R2 becomes a
new, legitimate endpoint (let's say E3). An SA from Sgw2 to Sgw1 for
carrying E3 to E1' ICMP traffic is negotiated and utilized. The
parameters of this SA will be entirely up to the O&M group.
ICMP traffic from E2' to E1':
Handle as per IPSec selector specifications on Sgw2. It is
recommended that even when E2 is more narrowly idenified than an IP
address, that protocol=ICMP be configured to fit in the selector.
New requirements for IPSec Security Gateways.
o a per interface ICMP allow/deny/if-match-endpoint-IP config toggle
o a per interface trust ICMP error frag-needed toggle
o a per interface trust ICMP error TOS deny toggle
o when generating an ICMP error, MUST bundel entire original IP
datagram and clear DF bit.
o Never send ICMP errors to an ISAKMP peer.
--------------------------------------------------------------------------------
Follow-Ups:
Re: ICMP in IPSec
From: Ari Huttunen <Ari.Huttunen@lmf.ericsson.se>
Re: ICMP in IPSec
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Re: ICMP in IPSec
From: "Loretta Zhou" <lzhou@nortelnetworks.com>
--------------------------------------------------------------------------------
Prev by Date: Re: IKE transport (was INITIAL-CONTACT issues)
Next by Date: ISP's who assign unrouteable addresses
Prev by thread: RE: draft-ietf-ipsec-policy-schema-00.txt
Next by thread: Re: ICMP in IPSec
Index(es):
Main
Thread
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com