Re: [Ipsec] new ICMP text for 2401bis

[Mark Duffy <mduffy@quarrytech.com>]

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?


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


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

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.


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

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


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


>  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


>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


>                                           it extracts the header info from
>      the payload, reverses the source and destination IP addresses, and, if
>      accessible, the source and destination port fields. It uses the address,
>      protocol, and port fields (if available) to perform an SPD lookup. If an
>      appropriate, extant SA is found, the packet is transmitted via this SA.
>      (No new SA will be created to carry an ICMP error packet.) If no 
> suitable
>      SA exists, the ICMP packet is dropped, an auditable event.
>
>    b. If an IPsec implementation receives an ICMP error packet on an SA 
> and the
>      traffic selectors for that SA do not allow for the packet, a secondary
>      check is performed. The receiver extracts the header info from the ICMP
>      payload, reverses the source and destination IP addresses, and, if
>      accessible, the source and destination port fields. The resulting values
>      are compared to the selectors for the SA via which the ICMP packet was
>      received. If the selectors match, the packet is forwarded, otherwise it
>      it is discarded, and auditable event.

[...]


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