Subject: Re: Re: [Ipsec] RFC 4301 and ICMP processing

From: "DIPANJAN DATTA" <[email-masked]>
Date: 1 Aug 2007 07:19:33 -0000

Hi All,

The confusion in understanding the Section 6.2 seems to arise from the fact that demarcation of Outbound & Inbound processing is not very clear. Actually any traffic arriving to an IPsec implementation from the protected interface towards the unprotected interface is supposed to have Outbound Processing & any traffic arriving from the unprotected side towards the protected side is supposed to go through Inbound Processing.

In this case for the ICMP error packet generated by RTR1, from GW2's perspective is arriving from a protected interface side towards unprotected side and hence a candidate for Outbound Processing. The scenario will be same had the ICMP error packet been generated by GW2 itself. What Outbound Processing will be done by GW2 on the ICMP packet depends on SPD rules at GW2, as Stephen rightly mentioned.
The rules can be:
1) Separate SPD entry for ICMP packets.
OR
2) Same SPD entry as used for traffic between H1 & H2.

In case (2), GW2 will extract the source & destination IP address and protocol & port fields from the original packet that triggered the ICMP error, reverse them and map it to an extant SA. If no such SA exists, DISCARD the packet.

From GW1's perspective such a packet (either case (1) or case (2))
is arriving from an unprotected side towards its protected side and hence a candidate for Inbound Processing. It will map the packet to an extant SA. If no such SA exists, DISCARD else process accordingly.
If case (2), after Inbound SA processing, additional check MUST be made by extracting the source & destination IP + protocol & port fields of the original packet (that triggered the ICMP error) to check if everything is consistent with the SA on which the ICMP error packet arrived.

Regards
Dipanjan Datta

On Wed, 01 Aug 2007 Stephen Kent wrote :
>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
>_______________________________________________
>Ipsec mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec