[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [Ipsec] RFC 4301 and ICMP processing
From: Scott C Moonen <smoonen () us ! ibm ! com>
Date: 2007-07-31 20:08:18
Message-ID: OF29483CE3.E4215DCA-ON85257329.006E4D2A-85257329.006E5A4B () us ! ibm ! com
[Download RAW message or body]
This is a multipart message in MIME format.
This is a multipart message in MIME format.
--=_alternative 006E541085257329_=
Content-Type: text/plain; charset="US-ASCII"
Thanks for the very quick response, Stephen!
Scott Moonen (smoonen@us.ibm.com)
http://scott.andstuff.org/
Stephen Kent <kent@bbn.com>
07/31/2007 03:44 PM
To
Scott C Moonen/Raleigh/IBM@IBMUS
cc
ipsec@ietf.org
Subject
Re: [Ipsec] RFC 4301 and ICMP processing
At 11:52 AM -0600 7/31/07, Scott C Moonen wrote:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary=-------z66_boundary_sign
In section 6.2, RFC 4301 requires the use of additional checks to verify
whether an ICMP packet is consistent with an SA's selectors. When sending
or receiving an ICMP packet, if there is no existing SA or SPD entry to
match the ICMP error, then the ICMP packet is allowed to traverse the same
SA that its embedded packet would have traversed.
It is reasonably clear what is to be done for an end-to-end SA, but the
RFC's language is unclear as to whether this is required for a gateway SA.
Consider the following setup:
H1 ----- GW1 ===== GW2 ----- RTR1 ----- H2
Host H1 sends a UDP packet to H2 that is encapsulated in an IPsec tunnel
between gateways GW1 and GW2. My question is this: If RTR1 originates an
ICMP error for this packet that traverses the same path in reverse, should
GW2 encapsulate the ICMP packet in the original UDP SA (in the absence of
other rules for carrying the ICMP packet), and should GW1 allow the
encapsulated ICMP packet to arrive over that UDP SA?
4301 allows GW1 and GW2 to handle this situation in either of two ways. An
SPD can say that the SA for the H1/H2 traffic ALSO can carry ICMP
messages, or the SPD can call for creating a separate SA between the two
GWs to carry only ICMP messages. So, the answer to your question depends
on the contents of the SPDs at GW1 and GW2.
In the case of GW1 allowing the ICMP packet to exit the tunnel and be
forwarded, the RFC hints strongly that this should be the case. The last
sentence of section 6.2 speaks of cases where the ICMP must not be
forwarded,
The intent of the last sentence in 6.2 is to emphasize that if an ICMP
packet is received on an inbound SA and cannot be verified via the
procedure outlined in 6.2, then it MUST be discarded, not forwarded.
Section 6.2 does not express a strong preference for either of the
approaches to carriage of ICMP traffic defined in this section. Compliant
implementations MUST support both approaches, e.g., the text says "To
accommodate both policies, ..." .
strongly implying that GW1 is normally expected to forward in this case.
But it is less clear that GW2 should encapsulate ICMP errors in non-ICMP
SAs for errors that it has not originated. Section 6.2 speaks only of
performing this encapsulation for "outbound" ICMP errors, and of ICMP
errors "sent and received via SAs." What if GW2 is doing forwarding but
not sending?
The ICMP errors are outbound whether they are generated by the security
gateway or by a host or router behind the SG. So whether the GW is
generating the ICMP error message itself, or forwarding it, the treatment
is the same at this stage of processing.
I'm inclined to think that GW2 should encapsulate any ICMP error according
to these rules, even routed ICMP errors which it did not itself originate.
That's controlled by the SPD.
This is parallel with the fact that GW1 seems to be expected to behave in
the reverse manner, and also aligns with the use of "outbound" at other
points in the RFC to be inclusive of forwarded traffic. The one concern I
can see is that ICMP errors that GW2 did not originate are considered less
trustworthy and we may not wish to apply this processing to them. However,
it is possible to prevent this by creating additional SPD entries at GW2
to prevent untrustworthy ICMP errors from entering the gateway in the
first place.
yes, the GW could elect to not forward ICMP traffic from routers behind
it, for security reasons.
Am I correct in assuming that section 6.2 of RFC 4301 is intended to
address both local and forwarded ICMP traffic? Or is the treatment of
forwarded traffic left to the discretion of each implementation?
As I noted above, the intent of 6.2 is to accommodate both locally
generated and forwarded ICMP traffic.
Steve
--=_alternative 006E541085257329_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Thanks for the very quick response,
Stephen!</font>
<br><font size=2 face="sans-serif"><br>
Scott Moonen (smoonen@us.ibm.com)<br>
http://scott.andstuff.org/</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Stephen Kent <kent@bbn.com></b>
</font>
<p><font size=1 face="sans-serif">07/31/2007 03:44 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Scott C Moonen/Raleigh/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">ipsec@ietf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ipsec] RFC 4301 and ICMP processing</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3>At 11:52 AM -0600 7/31/07, Scott C Moonen wrote:</font>
<br><font size=3>Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";<br>
micalg=sha1; boundary=-------z66_boundary_sign</font>
<br><font size=2><br>
In section 6.2, RFC 4301 requires the use of additional checks to verify
whether an ICMP packet is consistent with an SA's selectors. When
sending or receiving an ICMP packet, if there is no existing SA or SPD
entry to match the ICMP error, then the ICMP packet is allowed to traverse
the same SA that its embedded packet would have traversed.</font><font size=3><br>
</font><font size=2><br>
It is reasonably clear what is to be done for an end-to-end SA, but the
RFC's language is unclear as to whether this is required for a gateway
SA. Consider the following setup:</font><font size=3><br>
</font><font size=2><br>
H1 ----- GW1 ===== GW2 ----- RTR1 ----- H2</font>
<br><font size=2>Host H1 sends a UDP packet to H2 that is encapsulated
in an IPsec tunnel between gateways GW1 and GW2. My question is this:
If RTR1 originates an ICMP error for this packet that traverses the same
path in reverse, should GW2 encapsulate the ICMP packet in the original
UDP SA (in the absence of other rules for carrying the ICMP packet), and
should GW1 allow the encapsulated ICMP packet to arrive over that UDP SA?</font>
<br>
<br><font size=3>4301 allows GW1 and GW2 to handle this situation in either
of two ways. An SPD can say that the SA for the H1/H2 traffic ALSO can
carry ICMP messages, or the SPD can call for creating a separate SA between
the two GWs to carry only ICMP messages. So, the answer to your question
depends on the contents of the SPDs at GW1 and GW2.</font>
<br>
<br><font size=2>In the case of GW1 allowing the ICMP packet to exit the
tunnel and be forwarded, the RFC hints strongly that this should be the
case. The last sentence of section 6.2 speaks of cases where the
ICMP must not be forwarded,</font>
<br>
<br><font size=3>The intent of the last sentence in 6.2 is to emphasize
that if an ICMP packet is received on an inbound SA and cannot be verified
via the procedure outlined in 6.2, then it MUST be discarded, not forwarded.
Section 6.2 does not express a strong preference for either of the approaches
to carriage of ICMP traffic defined in this section. Compliant implementations
MUST support both approaches, e.g., the text says "</font><font size=5 face="Courier">To
accommodate both policies,</font><font size=3> ..." .</font>
<br>
<br><font size=2> strongly implying that GW1 is normally expected
to forward in this case. But it is less clear that GW2 should encapsulate
ICMP errors in non-ICMP SAs for errors that it has not originated. Section
6.2 speaks only of performing this encapsulation for "outbound"
ICMP errors, and of ICMP errors "sent and received via SAs."
What if GW2 is doing forwarding but not sending?</font>
<br>
<br><font size=3>The ICMP errors are outbound whether they are generated
by the security gateway or by a host or router behind the SG. So whether
the GW is generating the ICMP error message itself, or forwarding it, the
treatment is the same at this stage of processing.</font>
<br>
<br><font size=2>I'm inclined to think that GW2 should encapsulate any
ICMP error according to these rules, even routed ICMP errors which it did
not itself originate.</font>
<br>
<br><font size=3>That's controlled by the SPD.</font>
<br>
<br><font size=2> This is parallel with the fact that GW1 seems to
be expected to behave in the reverse manner, and also aligns with the use
of "outbound" at other points in the RFC to be inclusive of forwarded
traffic. The one concern I can see is that ICMP errors that GW2 did
not originate are considered less trustworthy and we may not wish to apply
this processing to them. However, it is possible to prevent this
by creating additional SPD entries at GW2 to prevent untrustworthy ICMP
errors from entering the gateway in the first place.</font>
<br>
<br><font size=3>yes, the GW could elect to not forward ICMP traffic from
routers behind it, for security reasons.</font>
<br>
<br><font size=2>Am I correct in assuming that section 6.2 of RFC 4301
is intended to address both local and forwarded ICMP traffic? Or
is the treatment of forwarded traffic left to the discretion of each implementation?</font>
<br>
<br><font size=3>As I noted above, the intent of 6.2 is to accommodate
both locally generated and forwarded ICMP traffic.</font>
<br>
<br><font size=3>Steve</font>
<br>
--=_alternative 006E541085257329_=--
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic