Re: [Ipsec] new ICMP text for 2401bis

[Stephen Kent <kent@bbn.com>]

At 5:34 PM -0400 8/17/04, Mark Duffy wrote:
>Steve, sorry about the delayed response.  Please see some comments below.
>--Mark
>
>At 05:01 PM 8/9/2004, Stephen Kent wrote:
>[...]
>>6.1 ICMP message not protected by IPsec
>>
>>An ICMP message not protected by AH or ESP is unauthenticated and 
>>its processing and/or forwarding may result in denial or 
>>degradation of service.  This suggests that, in general, it would 
>>be desirable to ignore such messages. However, many ICMP messages 
>>will be received by hosts or security gateways from unauthenticated 
>>sources, e.g., routers in the public Internet. Ignoring these ICMP 
>>messages can degrade service, e.g., because of a failure to process 
>>PMTU message and redirection messages. Thus there is also a 
>>motivation for accepting and acting upon unauthenticated ICMP 
>>messages. To accommodate both ends of this  spectrum, a compliant 
>>IPsec implementation MUST permit a local administrator to configure 
>>an IPsec implementation to accept or reject unauthenticated ICMP 
>>traffic.  This control MUST be at the granularity of ICMP type and 
>>MAY be at the granularity of ICMP type and code.
>
>No disagreement here with requiring that control, but wouldn't the 
>SPD (already covered under other MUSTs) generally be sufficient to 
>meet this requirement?

In Figure 3 in 2401bis we show processing of unprotected side, 
inbound ICMP traffic in its own box, not crossing the IPsec boundary. 
Also, if we want to do something like place a restriction on how 
small a PMTU size we are willing to believe based on an 
unauthenticated ICMP message received on this side(the example 
below), that is not the kind of thing we express via the SPD.


>>   Additionally, an implementation SHOULD incorporate mechanisms and 
>>parameters for dealing with such traffic. For example, there could 
>>be the ability to establish a minimum PMTU for traffic (perhaps on 
>>a per destination basis), to prevent receipt of an unauthenticated 
>>ICMP from setting the PMTU to a trivial size."  [See Section xxx 
>>for recommendations.]
>
>Is that SHOULD intended to apply to ICMP messages that are 
>forwarded, or those that are addressed to the IPsec implementation 
>itself, or both?

I intended for this to apply to unauthenticated messages, not ones 
arriving on an SA, so they would be addressed to the IPsec 
implementation itself. However, I was not thinking about messages 
that are bypassed, when I wrote that. Such messages must be accounted 
for in the SPD, or they would not be allowed across the IPsec 
boundary, but I am not suggesting that such messages, if bypassed, 
need to be subjected to additional "reasonableness" checks.

>>6.2 ICMP messages protected by IPsec
>>
>>(This section does NOT apply to ICMP traffic that is bypassed or 
>>consumed on the ciphertext side of the IPsec boundary.)
>>
>>Both the payload of an ICMP error packet, and the header of the 
>>ICMP packet require checking from an access control perspective. If 
>>one of these packets is forwarded to a host behind a security 
>>gateway, the receiving host IP implementation will make decisions 
>>based on the payload, i.e., the header of the packet that 
>>purportedly triggered the error response. Thus an IPsec 
>>implementation SHOULD to try to ensure that this header information 
>>is
>>consistent with the IPsec peer that transmitted the ICMP packet.
>
>I don't think it is clear what it means to "ensure that this header 
>information is consistent with the IPsec peer that transmitted the 
>ICMP packet".  How about
>"Thus an IPsec implementation receiving an IPsec protected ICMP 
>message SHOULD try to ensure that the ICMP payload information is 
>consistent with packets that would be sent on the SA pair on which 
>the ICMP message was received."

Howe about:

"An IPsec implementation MUST be capable of being configured to 
verify that the ICMP payload information is consistent with packets 
that would be sent on the SA pair on which the ICMP message was 
received."

>Why is this a SHOULD, but then below the specific actions required 
>to achieve this are MUST?  On the other hand, MUST isn't correct 
>here either because in the case where there is an SA for the ICMP 
>packet in its own right, this special check on the ICMP payload is 
>not being called for.  Maybe it should say it MUST do this under 
>certain conditions as described below.

My revised text makes the ability to do this a MUST, but also 
recognizes that one can choose to configure the SPD so that this will 
not happen.

>>  If this sort of check is not performed, then for example, anyone 
>>with whom the receiving IPsec system (A) has an active SA could 
>>send an ICMP destination dead message that refers to any host/net 
>>with which A is currently communicating, and thus effect a highly 
>>efficient DoS attack re communication with other peers of A. 
>>Normal IPsec receiver processing of traffic is not sufficient to 
>>protect against such attacks.
>>
>>If no SA exists that matches the traffic selectors associated with 
>>an ICMP error packet,
>
>I don't think that should say "if no SA exists ...".  Rather, I 
>think it should say "if no SPD entry exists that matches the traffic 
>selectors associated with an ICMP error packet".  I agree with the 
>point below that it should not negotiate a new SA to forward an ICMP 
>under the special processing rules (based on the ICMP payload).  But 
>I think it *should* negotiate a new SA if needed when operating 
>under the usual rules (i.e. if there is an SPD entry that natively 
>matches the ICMP packet).

My rationale was that since we are talking about ICMP error messages, 
they should never cause an SA to be created, because they should be 
sent only in response to receipt of a packet that arrived over an SA, 
causing the error in question. Hence I did mean that we should never 
create an SA to carry these messages.

>I assume that this would refer to SPD entries of any flavor 
>(discard, bypass, protect) and so it is only if there is no SPD 
>entry at all that matches the ICMP packet that it should then 
>consider doing the special outbound processing described next...

yes, it applies to all SPD entry types.

>>then an IPsec implementation MUST map an outbound ICMP error packet 
>>to the SA that would carry the return traffic associated with the 
>>packet that triggered the ICMP error packet. (This allows an 
>>administrator to explicitly account for ICMP error packets in SPD 
>>entries, causing them to bypass the payload check noted below. This 
>>results in reduced security for hosts, as noted above.) This 
>>requires an IPsec implementation to detect outbound ICMP error 
>>packets that map to no extant SA,
>
>Pursuant to my point above, "that map to no extant SA" would need a 
>corresponding change to refer to SPD policy rather than extant SA.

see my response above re this issue.

>>  and treat them specially with regard to SA creation and lookup. 
>>The implementation extracts the header for the packet that 
>>triggered the error (from the ICMP message payload), reverses the 
>>source and destination IP address fields, extracts the protocol 
>>field, and reverses the port fields (if accessible). it them uses 
>>this extracted information to locate an appropriate, active 
>>outbound SA. This implies that there must be an active SA for that 
>>traffic. An IPsec implementation MUST NOT create a new SA carry 
>>ICMP traffic error packets as a result of an attempt to transmit 
>>such packets.
>>
>>If an IPsec implementation receives an IMCP error packet that does 
>>not match the SA traffic selectors, the receiver also MUST process 
>>the received message in a special fashion. Specifically, the 
>>receiver must extract the header of the triggering packet from the 
>>ICMP payload, and reverse fields as described above to determine if 
>>the packet is consistent with the selectors for the SA
>
>s/if the packet/ if the triggering packet/    -- would add some clarity

OK< we'll make the suggested change here.

>>via which it was received. Only then is it safe to forward the ICMP 
>>message to the destination.
>>
>>The sender and receiver MUST support the following processing when 
>>ICMP error packets are sent over SAs with selectors that DO NOT 
>>match these packets:
>>
>>    a. If an IPsec implementation encounters an outbound ICMP error message
>>       for which no applicable SA exists,
>
>as argued above, this should be a reference to SPD policy, not extant SA

see response earlier.


[SNIP]

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec