Subject: [Ipsec] RFC 4301 and ICMP processing

From: Scott C Moonen <[email-masked]>
Date: Tue, 31 Jul 2007 11:52:24 -0600

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?

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, 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?

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. 
 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.

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?

Thanks in advance for your response,

Scott Moonen ([email-masked])
http://scott.andstuff.org/

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Tue, 31 Jul 2007 15:44:31 -0400

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:
>
>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.

>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

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 31 Jul 2007 16:08:18 -0400

Thanks for the very quick response, Stephen!

Stephen Kent <[email-masked]> 
07/31/2007 03:44 PM

To
Scott C Moonen/Raleigh/IBM@IBMUS
cc
[email-masked]
Subject
Re: [Ipsec] RFC 4301 and ICMP processing

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.

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.

yes, the GW could elect to not forward ICMP traffic from routers behind 
it, for security reasons.

Steve